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.

y