Assuming/hoping there will at some point be a registry where one can download r7rs libraries (maybe there already is? snowfort?), I think it can be as simple as suggesting people use their library name as it occurs in the registry as a prefix.
Yes, snow-fort.org already has a nice collection of R7RS libraries. It doesn't enforce any particular library name conventions.
We should set up something like lib.scheme.org that aggregates everything. Scheme.org news coming soon.
Nevertheless, experience with golang shows that arbitrary URI imports are still a good idea. There are so many Go packages that they cannot hope to gather all of them in one registry, no matter how nice that would be.
This is lightweight, easy to understand and remember, and not as ugly or fraught with issues like the URI proposal.
Do you have specific issues in mind with the URIs?
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
That would be a problem because then you'd need an additional mapping of URL to filesystem location for the module. A colon is not allowed in Windows file names, more than one dot might be a problem in some OSes as well, and slashes can't occur in file names either. There's many more specifal characters:
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations
So an e-mail address might not work either.
Good call.
I have a generic solution in mind to the filename mapping mess that would involve having a special metadata file in the lib directory. That file could have instructions about library lookup and compatibility, which would then drive a small library name rewriting engine in the Scheme implementation. By rewriting, I mean things like "assume all library names of the form (srfi-NNN) are aliases to equivalent names of the form (srfi NNN), and those can be found at filenames of the form srfi/NNN.sld".