I personally think it is time to standardize Result, and I believe that several other core team members feel the same way. The major problem with doing so is that is blocked by an unresolved disagreement (in both the core team and community): whether Swift should support typed errors.
If we add typed throws, then I believe that the design is clear: throws would allow at most one type to be specified, and if none is specified, Error is the default:
func foo() throws {
func bar() throws Error { // same as above
func baz() throws MyEnum { // ok
While many people will argue for a list of possible thrown things, there are lots of reasons not to do that, not least of which is that you can represent such a list of options with an enum.
Whether we add this or not ends up impacting Result. In a world without typed throws, we should define result as Result. If we have typed throws, we should have Result<NormalResultType, TheErrorType>.
On this core disagreement, there are lots of reasonable arguments on both sides, but it would be healthy to start hashing those out (in its own thread). We don't need to actually implement typed throws to get result, we just need a decision about whether we should implement it one day. Not making that decision continues the sad state of affairs where we don't have a standardized Result type.
-Chris