This is a more minor concern than my previous note, but also important.

The srfi uses the term "path" in mutual confusing ways.  Richard
Stallman impressed upon me--and I think he's quite right--that Unix has
traditionally used the word "path" in two quite different senses.

Sense one means by a path a sequence of directory names, separated on
Unix with a slash.  When we say that "/usr/include/stdio.h" is a path,
this is sense 1.

Sense two means a list of sense-one paths, often written with a colon as
separator between them, identifing a list of directories to search to
find a file.  When we say that your PATH
is /bin:/usr/bin:/usr/local/bin, this is a sense-2 path.

The GNU Project has abandoned this systematic ambiguity and never uses
the word "path" in sense-1, sense there is the perfectly good "filename"
already.  I believe that Posix as well never uses "path" in sense-1, but
I can't recall exactly.  (Historically, "filename" referred in Unix to
the entry in a specific directory, but those days are gone.)

The srfi introduces the concept of a "library file path", which is a
sense-1 path, and which is essentially a specification of the format of
an r5rs/r6rs "filename", and a re-specification of a Unix filename.

Can I request that the srfi drop the attempt to call filenames "path
names", and stick to "path" specifically in the context of a search
path?

Thomas