A couple of empirical observations.
One compelling ergonomic advantage of this proposal which has intrigued me is the ability to turn an infallible function into a fallible one with a minimum of editing (see this post), so I attempted to find out how often the situation arises.
From a global alphabetical search on crates.io I filtered the first 1000 crates published in the previous year with at least five versions and a valid publicly accessible repository. Then I cloned each repository and searched all commits in the default branch for a combination of an added fn returning Result and a removed fn of the same name without a Result in the return type.
About 15% of repositories had at least one matching commit.
I don’t have a definitive analysis, but I suspect that my method produces a lot of false positives. I checked about 20 repos by hand, and found that matching commits in less than a half of them actually represented the transition to a fallible function. Some matches covered the use of type aliases; some caught refactorings which removed an infallible function and introduced unrelated fallible functions of the same name, etc. I believe that 7-10% is a more realistic result.
On the face of it, that’s not much. However, I’m aware that a search of this kind simply can’t detect things like exploratory integration and refactoring, where the ergonomic burden of switching between fallible and infallible versions exists as well. So, take with a grain of salt.
Another, and much easier, search was for a bare Ok(()) somewhere in the source, excluding tests and examples. About 46% of repositories had at least one.
As for my opinion on the syntax, I’d prefer to see Result verbatim in the return type. If bikeshedding is permitted, my preference would be for something like fn x() -> wrap Result<_, _> { ... } which would avoid the connotations of catch and fit nicely with Option. I know that catch is already reserved, and I’m not opposed to it in general.