> If github.com/scheme-requests-for-implementation was the only place where libraries can be found then yes this convention would be fine.  But there are other libraries than SRFIs and other “consumers” of the sample implementations than humans (e.g. package installers).
>
> Given the special status of the SRFI web site in setting Scheme standards, I would expect that it follow a standard layout for libraries so that it is easier to remotely access the sample implementations without making a special case for each one, or for SRFIs (vs. other sites where libraries can be found).

I agree that a standard layout would be a good thing.

But a SRFI's repo has to be able to house more than one sample
implementation. The only sensible way to do that is to put each
implementation in its own subdirectory.

I don't see any practical layout that would translate directly to a good
URL/subdirectory combination. The Linux distros have been wrestling with
problems like this, and it's generally not possible to establish
conventions at scale. The solution is free-form indirection mechanisms
(symlinks, HTTP redirects, etc.)

> I’m thinking of extending Gambit’s define-module-alias form to allow a pattern language, similarly to quasiquotation and some “match” macros, so that (import (sample-srfi 233)) can be mapped to the sample implementation using something like
>
> (define-module-alias (sample-srfi ,N) (github.com/scheme-requests-for-implementation ,N srfi ,N))
>
> Note that with the current layout srfi-${N}/srfi/${N}.sld the alias needed would rather be
>
> (define-module-alias (sample-srfi ,N) (github.com/scheme-requests-for-implementation srfi-,N srfi ,N))
>
> in other words the repository name needs to be constructed by prepending “srfi-” to the SRFI number.  This is not very Schemey (indeed syntax-rules does not allow such a thing).
This is a good start.

IMHO it's important to differentiate between:

(1) libraries already loaded

(2) libraries available for loading

Set (1) only changes by loading (or unloading) libraries.

Set (2) can change implicitly when files or internet hosts come and go.
It can also change if you tweak the search path or other settings.

Notably: it's possible to load a library from set (2), bringing it into
set (1), then change some settings such that the library disappears from
set (2) while still continuing to work fine in set (1).

For this reason, sets (1) and (2) should be kept conceptually separate.
That's tricky since both sets use similar-looking library names.

It's not clear whether "define" is a good word to use when talking about
set (2) since that set is somewhat ephemeral. (In principle, it's the
user's business where he wants to find libraries, so he's free to change
loader settings at any time. As Marc N-W has pointed out, the Scheme
language as such is not really affected by where and how libraries are
loaded; that's the business of the implementation and OS.)