When I initially proposed to write a SRFI like this one, the idea was
a very simple one: Just replace ":XXX" with "srfi-XXX" and make the
new library a perfect alias for the other.

In the final draft, simplicity is given up by introducing a third form
of naming, namely "NAME-XXX", which is not homomorphic to the other
two schemes. Moreover, it is not faithful to the idea of using
structured S-expression to name libraries because the name is
concatenated with the number as a string. SRFI 97 chose the better
convention, which should be retained.

That the "NAME-XXX" scheme is only optional doesn't make things
better. Portable code won't be able to rely on it, and code may
accidentally become unportable because the developer's system may
support this extra scheme, but not some target system.

To fix this draft, please remove the "NAME-XXX" scheme again and
return to the minimal change needed to make SRFI 97 better behaved
with respect to typically allowed filenames. For example, when this is
done, one of the SRFI 41 libraries will be called "(srfi srfi-45
streams derived)". (Does the current SRFI say anything about SRFI
sublibraries?)

PS A totally different approach to solve the problem that is the
raison d'être for SRFI 261 would be to mandate that implementations do
not look up implementations for libraries named "(srfi :XXX ...)"
under paths that would need a specific encoding ":". Note that there
is no canonical mapping between library names and pathnames (not even
a bijective one), nor do libraries have to be stored as individual
files, so essentially, in a perfect Scheme world, there would be no
reason to give up the ":XXX" convention.

Am Di., 7. Okt. 2025 um 02:45 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> WANG Zheng, author of SRFI 261: Portable SRFI Library Reference, has asked me to announce last call for this SRFI. He believes that it is ready for finalization, but would like to give reviewers one last chance to submit corrections and feedback before we finalize it.
>
> If you're interested in this SRFI, please give your feedback via the SRFI 261 mailing list before 2025-10-20. After that, assuming that no major revisions are required, we will declare it final. It is important that we get your feedback before 2025-10-20. If that deadline is too soon for you, but you would like to contribute, please let me know so that I can extend the last-call period.
>
> Regards,
>
> SRFI Editor