There seems to be two parts to the rationale:

  - SRFI 7 isn't incremental or linear, so it's not designed to work
    interactively.
  - SRFI 7 doesn't specify the precise _loading_ of features' code.

I have several problems with this.  To the first part, I really don't
see any need for standardizing interactive features.  If you're using a
specific implementation's interactor, well, you're going to be doing
stuff that's really implementation-specific anyways, and to make an
attempt to standardize all interactive Scheme features would be simply
silly.  And anyways, SRFI 7's clauses could easily be adapted to some
form of interactive declarations.

The second part of the rationale is more significant.  First of all,
SRFI 7 defines a language for specifying the dependencies of a Scheme
program.  SRFI 7's intent is _not_ to specify a program loader -- for
example, a SRFI 7 processor for which it would make no sense to perform
loading of necessary features might be a dependency analyzer --; but
SRFI 7 _does_ suggest that a program loader exist somewhere in a Scheme
system that purports to support SRFI 7, and a useful program loader
_would_ indeed load the necessary features.  If someone wrote a SRFI 7
program loader that didn't actually load the features, why would they
write a SRFI 55 program loader that _did_?  (Unless that person had the
initials FLW and was the author of a Scheme->C compiler based on Henry
Baker's Cheney on the MTA garbage collection & compilation system...)
Furthermore, SRFI 7 even suggests that implementations that purport to
'support SRFI 7' provide a front end to their compilers or program
loaders for SRFI 7, whereas SRFI 55 doesn't even suggest that!

Now, I am also troubled by the design of SRFI 55.  It has the _exact_
same problems that Kelsey argued against in the SRFI 0 discussion list
and for which reason Kelsey 'responded' to SRFI 0 with SRFI 7!
Specifically, it is embedded in Scheme, which is utterly incompatible
with certain module system designs that cleanly separate the metadata
that the module system provides about the source and the source data
itself; in an example such module system, Scheme48's, it would require
absolute contortion to the system to make this operate correctly, and
so I can envision the Scheme48 developers to, indeed, _not_ provide a
useful program loader for SRFI 55, while it already has a useful one
for SRFI 7!

Now, if all you want is for SRFI 7 to specify that, if a program
loader is supported, it should try to load the necessary features, if
possible, (way too many conditional clauses there...sorry...), why
isn't this SRFI just a brief amendment to the wording of SRFI 7?

(Note: when I say 'program loader' in this email, I'm using a very
general term; it could be a procedure (LOAD-PROGRAM <filename>), a
command in an interactive command processor/REPL, a dynamic linker/
loader, a static linker, or anything.  I probably ought to have come up
with better terminology, but as long as I have this note here, it'll
probably be clear enough.)