> 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/xxxxxx@1.2.3 foo)
   (library bar) => (github.com/example/xxxxxx@1.2.3 bar)
   (library baz) => (gitlab.com/example/xxxxxx@1.2.3 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.