(0) As someone who has lobbied for making this SRFI
multiple-values-aware, I am, of course, delighted to see that multiple
values have made it into this draft.

(1) MAYBE-REF and EITHER-REF should call FAILURE and SUCCESS in tail context.

(2) In EITHER-REF, it should be an error if the default value of
FAILURE is invoked and the Left payload consists of zero or more than
one value. (This allows the implementation to do what is currently in
the spec, but it shouldn't be mandated because it somehow muddies the
idea multiple values. In a Scheme where the RAISE procedure is
multiple-values-aware and can thus take more than one value or zero
values, RAISE should be applied to the Left payload without a change,
which the current spec wouldn't allow.)

(3) The new interface to MAYBE-SEQUENCE and EITHER-SEQUENCE looks good
to me. I should make COMPUTATION-SEQUENCE of SRFI 166 compatible with
the final version (which should also go into an abstract monadic
framework). I would suggest making some arguments optional. The
default value of INNER-CONSTRUCTOR should be the VALUES procedure
(making it an error of a payload has more than one or zero values),
the default value of OUTER-CONSTRUCTOR should be the LIST procedure.
The default value of MAPPER should be `map'.

(4) The type of an object of name `mapper' should be listed in the
specification.

(5) How would the sequence operations look for a general monad?

(6) In LIST->MAYBE and LIST->EITHER the idea behind multiple values is
muddied. A Just with no values is in no way a Nothing. To preserve
these procedures for Maybes/Eithers with single-valued payloads, I
would strongly suggest making it an error if the LIST argument
contains more than one value or, in case of MAYBE->LIST, if MAYBE is a
Just containing not a single value. I am not yet sure what to do with
the procedure EITHER->LIST (also in view of EITHER->MAYBE).

(7) Please add versions of LIST->MAYBE and LIST->EITHER and vice versa
that are multiple-values aware. These versions would return #f in the
Nothing case. Here we are making use of the fact that in Scheme the
empty list is not #f, so we are not confusing a Just with no value
with a Nothing.

(8) If we allow MAYBE->EOF to be called on a Just without a single
value, for symmetry, EOF->MAYBE should take more than one value. The
same goes for LISP->MAYBE. However, I would rather make it an error to
use MAYBE->LISP and MAYBE->EOF in the multiple values case.

(9) Make it an error if MAYBE->VALUES and EITHER->VALUES are applied
to a Just/Right without a single value. An implementation would still
be free to choose what the current spec mandates, but it doesn't make
much sense logically.

(10) In the paragraph below VALUES->MAYBE and VALUES->EITHER, some
formatting seems to be wrong. I think the two procedures do too much;
they should be separated in the inverse of
MAYBE->VALUES/EITHER->VALUES (restricted to the single-value
situation) and MAYBE->LISP-VALUES/EITHER->LISP-VALUES.

(11) MAYBE-UNFOLD and EITHER-UNFOLD should take more than one value for SEED.

(12) MAYBE-IF shouldn't have to signal an error. This is not R6RS.