I think I now understand the nature of our disagreement.  You
say that SRFI-0 is portable because, given a known set of
available features, it is trivial to implement.  It makes no
difference to the SRFI-0 implementation how that set was chosen.
It might be a fixed set, it might be chosen by using a module
system, whatever, that's not the problem SRFI-0 is solving.

Now consider the point of view of an implementor with a module
system.  How do they load a program that uses SRFI-0?  If the
set of features needed were known in advance they would be home
free, but how to find out what those features are?  There is no
straightforward of doing so and the implementor concludes that
SRFI-0 is not portable and doesn't implement it.  That SRFI-0
is not intended to solve the problem of specifying which features
are needed doesn't matter; that problem still needs to be solved
before they implement SRFI-0.

Although SRFI-0 isn't intended to address the problem of specifying
which features a program needs, it can be used for doing so:

  (cond-expand (and srfi-1 srfi-3))

It's this usage that causes problems for module systems.  Users
are likely to be confused when a program containing this line
raises an error when loaded into an implementation that provides
SRFI-0, SRFI-1, and SRFI-3.  Explaining that the above form is
concerned only with conditional expansion and makes no statement
about whether SRFI-1 and SRFI-3 are needed to run the program is
unlikely to go over well.

If there were a widely-implemented module SRFI the problem would
go away.  COND-EXPAND could be used for when there really were
alternate chunks of code, as in your SRFI-18/SRFI-21 example
earlier.  The module system would be used in place of code-free
COND-EXPANDs like the one above, and I would agree with you
about SRFI-0's portability.

SRFI-7 isn't a way out, even if it were widely implemented, because
it isn't a module system and doesn't provide all the flexibility
of SRFI-0.
                                    -Richard Kelsey