It looks pretty good.  A couple of comments:

   Should export levels be specified?

I think that would be necessary for the goal stated in the abstract:

    ...there is a real need to organize these existing SRFI libraries so that
    they can be portably referenced.

I would suggest that the export level be assumed to be 0 for all exported
bindings of all SRFIs /except/ SRFI-46: Basic syntax-rules extensions, which
should export SYNTAX-RULES for level 1, provided the author agrees.
This would allow SRFI-46 to be portably imported and used without a (FOR ...)
clause (which, for example, the basic ERR5RS proposal lacks).

   Withdrawn SRFIs are not considered here. Should they be?

I would vote "no".

   ERR5RS: My hope is that this SRFI carries over without issue to ERR5RS. But
   someone who knows more about the library system of ERR5RS will have to
   evaluate this.

I am not aware of any issue.

   SRFI 9, Defining Record Types, and R6RS Records. What relation should SRFI 9
   records have with R6RS records?

I do not think any relationship should be assumed.  It might not be in
harmony with the intent of the author, but even if it is, assuming a
relationship would amount to an effective post-finalization modification or
extension of SRFI-9 itself, which would defeat the purpose of the actual
original SRFI process.

   SRFI 42, Eager Comprehensions, defines qualifiers, which are used as macro
   keyword literals, and some of these conflict with names provided by (rnrs
   base).
   Should anything be specified about these keywords (eg, should this library
   provide bindings?, the same bindings as in (rnrs base)?, etc.)?

This is a tricky one.  One has no choice but to export some bindings for the
conflicting literals (if, not, and, or).  If one re-exports the same
bindings as (rnrs base) for these conflicting literals, the library will be
more convenient to import into most programs.  However, one then cannot write a
program that uses SRFI-42 but that, at the same time, excludes the (rnrs base)
meaning of IF (as for example PLT 4 that excludes one-armed IF).
It would really be much cleaner to export different bindings for these literals,
but then they would have to be renamed if imported into an (rnrs base) program,
which is inconvenient.  Perhaps the author can be persuaded to use his
colon-based naming convention for keywords uniformly (making it :and, :or, ...
for uniformity with :range, ...).

Andre