Should this be binding as well?

That bit is just describing the let operators, there is a bit lower down that describes the and operators. I'm using "binding operators" to refer to both of those at once.

That makes perfect sense. Apologies for missing the local context!

I think it would make sense to keep the short description of the extension rationale at the beginning.

Starting with Users can define {\em let operators} may lost some users, even if they are somehow familiar with the notion of monads and applicatives.

I am wondering if it may also helps to make the link with the standard let clearer by introducing the identity monad as a toy example before the option monad.

I suspect that the identity monad is more likely to confuse people than help them, as it is the opposite of a motivating example: an example of when the new feature is useless.

Re. when to mention monads. We can't have it both ways. On one side people are concerned that mentioning monads at the beginning will scare off people who don't know what they are, on the other side you are concerned that not mentioning monads will scare off people who do know what monads are. I don't think it matters much, but I think I would lean towards something that is less likely to scare off beginners -- I trust people who know what a monad is more to work things out -- so I'd prefer to leave the first mention of monads to the rationale section.

It is clearly not possible to please everyone with the documentation in this case. If you think that the current state is better (or a good enough start), I am perfectly fine with it.

I was merely worried than, for people that don't know what are monads or applicatives, the interest of custom let-binding is hard to grasp on the fly.

I was merely worried than, for people that don't know what are monads or applicatives, the interest of custom let-binding is hard to grasp on the fly.

It does seem worth mentioning, but on the other hand, it can always be improved in subsequent commits.