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.
