Am Mo., 9. Juni 2025 um 14:55 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> As mentioned in a previous mail, I think the ideal naming convention for SRFI libraries, considering both ergonomics and the rules of R6RS, would have been of the form (srfi cond-expand-0), (srfi lists-1), etc.

This is not a good idea in my opinion, for at least two reasons:

(1) Contrary to SRFI 97, it restricts the space of usable textual
library name parts because there may be a reason to add a number
suffix to the textual name part for other reasons, and having two
number suffixes would simply be too confusing. Any convention
established by SRFI 261 must not decorate the freely choosable textual
name part.

(2) Inevitably, the convention proposed by you becomes ugly when R6RS
library versioning comes into play because the version numbers (which
are read left-to-right) would come directly after the SRFI number,
which is not related to versioning.

I do not even see what this suggestion tries to improve over SRFI
261's suggestion.

> Unfortunately, I also think that ship probably sailed with SRFI 97’s finalization; the situation where R7RS small allowed libraries with exact integer components in their names already led to one other competing convention. Adding another convention now (whether the Guile-like one this SRFI currently proposes, or the one I proposed) would risk only increasing the confusion.

> My original intention was to propose to the R7-large WG (for the bibliothecarial fascicle or a non-normative appendix thereto, i.e. not for a year or so yet) that a library name component which is an identifier starting with a colon, followed only by ASCII digits, should be understood by implementations as equivalent in all respects to a component which is an exact integer consisting of those decimal digits. This would be understood as an R6RS compatibility provision.
>
> On reflection, I still think that is a better solution, especially if we can also agree to start using the library names in the R7RS-style names.

The :NNN convention is very bad in practice and should not be
promoted. Maybe it was originally meant as a joke by Will Clinger or
not, but in any case, it makes life hard for R6RS users, and that
unnecessarily so.

[...]

#!r6rs-4 cannot work because the #!-syntax is not delimited. With
#!srfi-4, there could be no #!srfi-44.

Anyway, SRFI 261 has a clear goal and a clear area where it applies.
Trying to fundamentally change its contents through SRFI discussions
is probably  a sure way to cause the SRFI to be delayed ad infinitum.
Moreover, lexical syntax is a different problem, so it should be taken
care of in a different SRFI.