The description of maybe-compose in draft #7 is much clearer. I suggest distinguishing "values" (not the procedure, but the general sense) and "values wrapped by Maybe/Either" more strictly to avoid confusion.
That is, the third paragraph of maybe-compose currently says:
It is an error if one of the mprocs does not accept as arguments the number of values produced by its predecessor.
But what the predecessor produces is one value, Maybe or Either. So how about saying:
It is an error if one of the mprocs does not accept as arguments the number of values wrapped by Just/Right produced by its predecessor.
The description of maybe-bind can also be adjusted, because mproc can't be applied to maybe/either directly. How about something like this:
Monadic bind. If maybe/either is Nothing/ a Left, it is returned as is. If maybe/either is a Just/Right, it behaves as if they invoked maybe-compose/either-compose on mprocs and applied the resulting mproc to the payload of the Just/Right, returning the result Maybe/Either.
If it is not too verbose, showing the invariances in the srfi text would help to grasp their relations:
(maybe-compose x y z) == (maybe-compose x (maybe-compose y z))
== (maybe-compose (maybe-compose x y) z)
(maybe-bind m x y ...) == (maybe-bind m (maybe-compose x y ...))
== (maybe-ref m nothing (maybe-compose x y ...))
The reference implementation needs to be adjusted as well. The current definition of maybe-compose returns a procedure that takes one Maybe, not its payload(s). If Wolfgang is busy I can send PR.