> Library name rewriting is a useful feature.  However I think your example is backwards.  What is needed is a rewrite of (foo qux) to (github.com/account/repo foo qux).  It is important however that the place where this rewrite rule is expressed is as close as possible to where the library is referred to in the source code.  For example it could be a “config” or “alias” file that is in the same directory, or a parent directory (up to the root of the package).  A global alias file (that is part of the Scheme installation) is also a possibility but it should be a last resort as it is much more brittle (two users may get wildly different experiences if they have different global alias files).  What I’m advocating is a kind of lexical scoping of alias rules, where the directory nesting models the lexical nesting.

I agree that lexical scoping of rules is the right thing! Each Scheme
implementation should have its own default rules, which users and
packages can extend.

Following this line of reasoning, we could also have a SCHEME_PATH
environment variable that looks like the Unix path:

export SCHEME_PATH=/home/me/libs:/usr/local/share/scheme:...

But each entry in this path can be a package.

The "lib" directory of a Scheme implementation can contain the same kind
of metadata file that packages installable from Snow-Fort.org or Chicken
eggs have. That metadata file can have rewrite rules that say how Scheme
library names are mapped to filenames, whether they are R6RS and/or R7RS
compatible, etc.