An unconventional approach would be for the Scheme library names to
refer to a package index. The index would map library names to package
(e.g. git repo or tar file) URLs. So the user would import libraries and
the right packages would be consulted transparently.
From a security perspective, this requires the package index to be
trusted in addition to the git repos from which packages are fetched.
The index also needs to be updated frequently in order to present an up
to date picture of all available libraries. This is all quite a bit more
complicated than having the user type packages URLs directly into Scheme
(import ...) clauses.
In fact, this approach is identical to having the index as a package!
If the index says things like
(library foo) => (github.com/example/[email protected] foo)
(library bar) => (github.com/example/[email protected] bar)
(library baz) => (gitlab.com/example/[email protected] baz)
Then the natural way to implement the package index is to have it
download and cache those library files from the git repos, and serve the
cached files to Scheme implementations that request libraries from it.
The index could keep those cached files in a single git repo.
...and we have arrived at a situation that is conceptually the same as
fetching RnRS libraries from git repos, as far as the Scheme
implementation is concerned.
So your idea of having packages (as in, collections of RnRS libraries)
be a part of the library name in (import ...) is probably best.
