> In some sense, it can make a sound theory.  Namely, when the number of
> return values is undefined, something like
>
> (let ([x (set! y 4)])
>    ...)
>
> would be a typing error because the assignment expression could return
> not only one but also zero or more than one value.  Automated testing
> tools could exploit this.

I looked it up in R7RS. The term it uses is "unspecified". ("Undefined"
is used for an undefined variable in the formal semantics.)

"If the value of an expression is said to be "unspecified," then the
expression must evaluate to some object without signaling an error, but
the value depends on the implementation; this report explicitly does not
say what value is returned."

If I read that right, R7RS says an unspecified value must be exactly one
value, not zero or >1. That's too bad - I agree zero values would make
sense.

If an unspecified return could be "zero or more values", then the same
expression could return a different number of values each time. A test
can't reliably catch that.

> But always zero values would undoubtedly be better.

If there's a standard expression (unspecified) or (void), it could
return zero values in some implementations. (In an implementation with
real multiple values, a zero-value return will be coerce into some
default value when the receiver is expecting a value. So in that
implementation, it would not be much of a problem if (unspecified)
returns zero values even if we interpret RnRS to say that one value
should be returned.)