I haven't had time to read this draft SRFI carefully,
but I want to report several problems that I perceived
during my first quick reading:

1. Treatment of versioning.
2. Ignoring all contents after the first datum.
3. Failure to specify which characters are encoded.
4. Specification of ordering but not matching.
5. Implicit file names.

1. Treatment of versioning.

The R6RS does not specify any portable semantics for
versions, which was indubitably silly but had the
virtue of allowing implementations to ignore versions
altogether.

Implementations that support this draft SRFI would not
be able to ignore versions altogether.  They would be
required to implement *some* semantics for versions.
In particular, they would be required to implement a
semantics that is arguably inconsistent with the
intent of the R6RS editors.  Yet this draft SRFI still
stops short of requiring any portable semantics for
versions.

That sounds like the worst of all possible worlds.

In addition, the inclusion of versions changes the
mapping from library names from a one-to-many mapping
to a one-to-infinite mapping.  I understand that it's
implementable, but it changes the nature of the beast.
In particular, it would be harder for humans to map
library names to file names, which goes against one
of the the alleged goals of this draft SRFI; in
particular, it goes against the alleged rationale
for discarding all but the first library in a file
(see below).

2. Ignoring all contents after the first datum.

Taken literally, that is a recipe for disaster.  For
example, the R6RS permits implementations to extend
the lexical syntax of Scheme with a datum of the form
#!fold-case or #!larceny or similar, and many systems
have added such extensions.  Requiring all contents
that follow a #!fold-case datum to be discarded is
silly.

Requiring all contents to be discarded following the
first library is silly as well.  As demonstrated by
Larceny, allowing multiple libraries within a single
file reduces clutter.  I am not going to argue that
this SRFI should require implementations to support
multiple libraries within a file, but *requiring*
implementations to discard all but the first library
within a file serves no purpose other than to ensure
that Larceny will not support this SRFI.

This SRFI should state that files conforming to this
SRFI must have only one library per file.  This SRFI
should not require implementations to ignore all but
the first library in a file.

3. Failure to specify which characters are encoded.

If you don't specify which characters are encoded,
then one of two things will happen.  (I don't yet
understand the draft SRFI well enough to understand
which of the following disasters it would require,
but it would require one of them.)

One possibility is that different implementations
will require different sets of characters to be
encoded, so moving files of portable libraries from
one implementation to another will continue to
involve wholesale renaming of files.  Removing that
necessity, it seems to me, is the main thing this
SRFI should accomplish.

The other possibility is that every implementation
must support all possible sets of rules for encoding
characters, so the mapping from library names to
file names becomes one-to-infinite instead of the
one-to-many mapping that most implementations must
already support.  That makes implementations more
complex and more fragile.  It also makes collections
of portable code more complex and more fragile.  In
particular, it would be harder for humans to map
library names to file names, which goes against one
of the the alleged purposes of this draft SRFI; in
particular, it goes against the alleged rationale
for discarding all but the first library in a file.

4. Specification of ordering but not matching.

I don't even pretend to understand this issue, but
what is the point of specifying a detailed ordering
"as the precedence for choosing a match" if the actual
matching is going to be implementation-dependent?

One thing I *do* understand is that the R6RS
pseudo-semantics for versions is part of the problem
here.  This SRFI would do better to drop versions
altogether, as was explicitly urged by six voters
as one of the well-informed reasons they gave for
voting against ratification of the R6RS in the form
that was, unfortunately, approved.

5. Implicit file names.

If the reduction of clutter to be gained from
implicit file names were truly worth increasing the
number of files that must be examined in order to
locate a library, then this SRFI would allow more
than one library per file.  Allowing more than one
library per file would actually reduce the number
of files, instead of just allowing a small number
of special cases to be moved into a different
directory.

I'm not arguing that this SRFI should require
implementations to allow more than one library
per file so much as I'm arguing against implicit
file names.  If you won't consider the more useful
feature (which this draft SRFI would outlaw), then
it's silly to consider a much less useful and less
general special case.

Will