> A module-using Scheme that had SRFI-21 could translate this into
>
>    (module
>      (require srfi-21)
>      ...)
>
> One that had SRFI-18 but not SRFI-21 could translate it into:
>
>    (module
>      (require srfi-18)
>      (define (thread-priority-boost-set! thread boost) #f)
>      ...)
>
> No problem.

To me this approach (using SRFI-7) is not a realistic solution because
you lose modularity.  All of a system's requirements, and dependencies
on these requirements, have to be spelled out and handled in the
"program" form.  This may work for small systems, but it just won't
fly for systems with thousands of modules and lots of feature
dependencies.  The requirements and dependencies of a module should be
spelled out in the module, period!

SRFI-7 also has the problem that it views the program as a static
entity (no dynamic-loading of code, no REPL, etc).  One of the
beauties of Lisp languages is their dynamism, and this is lost with
the SRFI-7 approach.  Many languages (Java, Erlang, ...) have embraced
a dynamic model of execution, and it would be a shame to make this
"second-class" in Scheme that has had it from the start.  This does
not mean I am against static features in general, only that dynamic
features play an important role and should not be ignored (in fact
cond-expand is already a compromise between a static and dynamic
model, as discussed in the SRFI-0 document).

But note that this judgement of SRFI-7 is beside the point I was
addressing in my previous messages.  I am not trying to compare SRFI-0
and SRFI-7.  The point of my previous messages is that cond-expand is
compatible with module systems (of a certain type), and that they make
sense in that context, i.e. ****SRFI-0 in no way requires that all
features be built-in****.  cond-expand is a simple way for a piece of
code to adapt to the features of its execution environment.

Marc