Guile has sort of a love/hate-relationship with SCM_UNSPECIFIED as part
of its API.  A comment in boot-9 states:

;;; {The Unspecified Value}
;;;
;;; Currently Guile represents unspecified values via one particular value,
;;; which may be obtained by evaluating (if #f #f). It would be nice in the
;;; future if we could replace this with a return of 0 values, though.

There are, of course, lots of compatibility issues involved here.  Those
can be minimized by actually making *unspecified* exactly equivalent to
(values).  Since *unspecified* is used in a lot of places as a
first-class value, can be compared and stored in variables, the cost of
this equivalence is to allow (values) in single-value contexts.

I _think_ that we are talking about behavior undefined by the Scheme
standard here.  *unspecified* has been a pure Guileism anyway in all its
aspects.  (values), however, is firmly a standard Scheme construct, and
Guile often takes the choice to map undefined behavior in those
constructs to an error, making it easier to check for code being
portable.  Conflating (values) with *unspecified* has the consequence
that single-value contexts (such as an accessor like (car x)) may
deliver zero values to a multi-value accepting continuation by producing
*unspecified* as its single value and vice versa.

Accepting this drawback leads to a reasonably nice integration of
*unspecified* with values, making SCM_UNSPECIFIED the C level
representation of (values).

The incompatibility of this patch with Guile's existing code base and
regression test, arguably a complex code base, is limited to a single
failing test written under the assumption that (if #f #f) returns
exactly one value.  The first patch rewrites that test to get along
without this assumption.  The second patch does the actual work, the
third patch documents the changed semantics.