I'm really not sure what you're looking for here. The proposal (and the error manifesto before it) lays out a variety of use cases, as well as the philosophical differences between Swift current error handling and Result. So I believe the general usefulness of the type has been well established, as it's popularity within the Swift community attests.
Additionally, I would say that there is, in fact, consensus on the spelling of the type in almost all regards, considering the most popular implementations are almost identical. That popularity is another reason why it belongs in the standard library, in addition to its utility in general. Previous discussions of the type has centered almost solely around typed vs. untyped errors, with the spelling barely coming up. Of the nearly one hundred posts in this thread, and the over one hundred in the last, the spelling of the case names was mentioned a handful of times. To me, that's consensus.
Finally, as standalone types like this become more popular, collisions between user implementations and various library implementations become more common. For Result, we see occasional requests for Alamofire to use antitypical's Result implementation (we don't, since we have a strict no dependencies policy for the library), since they collide, and that library is used as a dependency for a variety of other libraries. All of this would be made much simpler and generally better by including the type in the standard library.