A couple of quick thoughts about the proposal:

I don't understand the motivation behind separating out may_fail and status. In the case where no explicit error is returned, we're happy to return an ordinary option. Why not return a status when we want to return an error condition? And I don't understand the argument about wanting to delay evaluation until the function result is called. Why is that good, and if it's good, why do we still support functions that return options? The whole thing seems to add verbosity with little gain.
I think some attention on nomenclature is in order. In the libraries Jane Street uses, we have something similar to status (called "result"), but the type is "Ok of 'a | Error of 'b" rather than "Success of 'a | Error of 'b", simply for terseness. Also, having a function called "result" which converts a "may_fail" into a "status" seems like one name too many. I would call both the function and the type the same thing (either status or result). Unless, of course, you want to imply something material about the operation, in which case calling it "eval" or somesuch would make sense.
I don't understand why this proposal is only for functional data types. I didn't find the motivation given in the OSR for this convincing. I feel like the use of exceptions involves roughly the same tradeoffs when you're using imperative and functional code. If you have long functional pipelines, doing exception handling at each stage is a pain, much as it is if you do long sequences of imperative operations. That's why I think the goal should not be for the interfaces to be "exceptionless" so much as to make it easier to keep track of where exceptions might and might not be thrown, so that the reader of a piece of code knows where to stop and worry about exceptions.