See #12015 (comment) for a new discussion item on qualified binding operators (some of Option.let/map, let/Option.map, Option.let+, etc.). I believe that the proposed feature has value even in absence of qualification: it can be used with local opens as we do for binding operators today, and the readability benefits still apply.

(I would still like to think about qualification because I think that Option.let/map or let/Option.map are nicer way to combine several modules than say mixing let/option and let/list.)

The plan is to eventually support a qualified form Option.let/map

My vote would be for let/Option.map even if it expands to Option.(let/map). I think that it is easier to read and it encourages people to define map and let/map as (semantically) the same function in a monad or applicative. That way you can read let/Option.map as essentially doing Option.map, just using a different identifier because e.g. you might want to label the function argument on your actual Option.map.

An alternative would be something like let/Option/map, which isn't too bad.

In any case there are conflicts with the Option.let/map syntax, as discussed in the discussion in #12015 (comment) . (I would rather focus in this PR on the discussion of the feature without module qualification, its desirability of course and its implementation.)

We discussed this PR at the maintainer meeting today. People are generally in favor, but they would like to see support for the qualified syntax, let/Option.map (which desugars into Option.( let/map ) before making a final decision on the feature.