> > Remember that an SRFI just describes a property of a Scheme system
> > which is more general than an API consisting of a set of procedures
> > and special forms. [...]
>
> True -- that issue I didn't know how to deal with.
>
> But then I'm having trouble seeing how `if-implements' could ever work if
> SRFIs ever conflict (as they will, especially when libraries are revised).
> It becomes an inherently a global operator, with no control over scope or
> conflict.

If two SRFI's conflict then it simply means that if-implements can't
say yes on both (i.e. both can't be implemented at the same time,
which is emminently reasonable since they conflict).  There is no
contradiction here.  Note however that a given Scheme system might
have two possible "modes" (for example selected with a command line
option) which implements different SRFI's in each mode.  In a sense
this Scheme system should be viewed as two Scheme systems which happen
to share most of their executable.

> It sounds, then, like a system which supports conflicting SRFIs could not
> support SRFI-0, which makes me uncomfortable -- I was hoping SRFI-0 could
> specify anchor from which all else could be determined.

It seems like you want a mechanism to **request** a specific feature
within some scope... this sounds very much like a module system.
SRFI-0 is not a module system, it is strictly a mechanism to **test**
that a specific property holds of the host Scheme system.  But you
could use SRFI-0 to test if a particular module system is available.

>   On the other
> hand, maybe some future SRFI could just contain a conflicting
> specification for `if-implements' in some clever mostly
> backward-compatible way, and SRFI-0 will become deprecated.

This is possible, but I REALLY REALLY hope this will not happen.
SRFI-0 (and the if-implements form) has to be as solid as a rock
because it is the basis on which the whole SRFI business rests.  That
is why it has to be simple and clear, and must find widespread
acceptance.  I hope noone ever has a reason to propose a new SRFI, say
SRFI-10, with a conflicting semantics for if-implements (for example,
reversing the direction of the two branches of the if-implements),
because a program containing

  (if-implements SRFI-1 *X* *Y*)

will be meaningless (since it is not explicit whether this refers to
the semantics of if-implements described in SRFI-0 or SRFI-10).  If
you ever feel the urge, at least consider a different name for the new
form (and perhaps the SRFI editors should enforce this).

Marc