As long as the issues I have raised repeatedly throughout the draft phase are unaddressed, I feel that finalizing this SRFI would damage the Scheme community and make writing portable code harder. It will create needless extra diversity in SRFI references rather than trying to fix the problem, making it harder either to write portable code or to write an implementation which supports as much portable code as it could, or both. The problem of a diversity of options in referring to SRFI libraries cannot be fixed by creating more options! I have referred to xkcd 927 before, but that is still literally what this SRFI proposes to do. After finalization, an implementation of both R6RS and R7RS will need to support yet more variety in SRFI name references.

The only way to make this better and not worse is to unify the two existing conventions:
• an R6RS library name component of the form :<digit 10>+ must be equivalent to an R7RS exact integer library name component, and implementations should look for such libraries in files whose names do not contain a leading colon (which is the entire ‘problem’ this SRFI really seems to set out to address, an invented ‘problem’ since neither R6RS nor R7RS say anything about a standard mapping of library names to file names)
• R7RS SRFI library names should be able to include the SRFI 97-style name identifiers; the current syntactic ambiguity about R7RS library names of the form (srfi nnn <identifier>) should be resolved by saying that <identifier> must not be a sublibrary name in future but a reference to the ‘whole’ SRFI library itself, with (srfi nnn <identifier> <identifier>+) being used for sublibrary divisions.

Moreover, it has still not been addressed that the ‘omits’ SRFIs from naming which actually already have names in their library metadata on srfi.schemers.org. Examples, I reiterate, are SRFIs 4 and 207. This SRFI needlessly throws the legitimacy of such authorial library name assignments into question. Arthur, I think as SRFI editor you ought to step in here and at the very least prevent this from happening. It would be damaging to the SRFI process to allow any doubt to be sown about whether such names are valid references.

To repeat what I have said before multiple times: every SRFI which exports identifiers should have a library name. If the SRFI also modifies lexical syntax, there also needs to be a way to activate the SRFI at the lexical level. The key word is ‘also’. These are two independent levels as far as the Scheme language is concerned; activating lexical syntax can never activate a library’s exports, nor vice versa. If this SRFI does not want to deal with the question of how lexical syntax is activated, that’s fine (though I don’t really understand the hesitation to address this problem) – but for libraries (like SRFIs 4, 88, 89, 207) which either introduce or depend on a lexical syntax extension, one *also* needs a way to import the identifiers they use.

Simply repeating the mistake of SRFI 97 by continuing to exclude SRFIs with library exports is not a good idea. It is an even worse idea when it delegitimizes the decisions of authors who have already independently seen through that nonsense reasoning and decided to fix it.

Please either fix this SRFI or withdraw it. Finalizing it would be a disaster.

> On 7 Oct 2025, at 02:44, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> 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