> R6RS allows zero or more than one value.

That's good.

> Additions to R[67]RS outside the standard libraries can enforce the
> "unspecified = zero values" convention without problems with backward
> compatibility.

Can, but probably should not since there are so many SRFIs and other
libraries written by dozens of people. Many of whom are out of reach.

A macro would be a smooth way to let individual Scheme implementations
solve this problem for themselves. With enough uptake, perhaps most of
them will converge on a solution one day, which can then be enshrined in
RnRS.

>> If there's a standard expression (unspecified) or (void), it could
>> return zero values in some implementations.

> That would be a good macro for writing code that has to work with
> several implementations and standards; but it shouldn't be in a
> standard itself.

We probably can't excise "unspecified" from RnRS at this point since
there are too many implementations. But kudos to anyone who tries.

> Coercing zero values into some default value is precisely what we
> don't want because it covers bugs.  It's a typing error and the
> implementation should not be silent about it.

Probably not a type error. Values are received into locations, which are
dynamically typed in Scheme. "Wrong number of locations" is different
from "wrong type of value in a location", no?

Intuitively, tuples have a similar nature to multiple values, but tuples
are objects. I'm starting to lean into the view that Lisp-style multiple
values are a mistake.