From SRFI 162:

> This SRFI provides a few extra procedures and comparators to go with SRFI 128, Comparators. Implementers are urged to add them to their SRFI 128 libraries, for which reason they are not packaged as a separate library.
Sorry, but this is madness :) How did this language make it past several
people into the final document?

Clearly (import (srfi 128)) should import the stuff in SRFI 128. We
can't expect the users of a SRFI to read other SRFIs to figure out who
put what procedures in whose library.

Just as clearly, we should not have a maze of Post-Finalization Notes
that refer to each other and must be understood as a web to use the
SRFIs correctly. Sprawling PFNs erode the meaning of the "final" status.

SRFIs are supposed to be finalized. Proposals which prove unstable
should be withdrawn, possibly to be submitted again as new SRFIs once
more experimentation has been done.

What if an old SRFI is fine except for a few missing procedures? It's
inevitable - that's going to be the fate of a lot of them. No harm done.
Users should import both the old and the new SRFI, or the new SRFI
should clone all the good stuff from the old.

> (Personally, I'd like that finalized srfis won't change except an apparent bug or oversight.  Any additional changes would be in a separate srfi library.

+1. I'd expect virtually everyone to want that.

> However, the libraries referred by a common name such as (scheme comparator) may evolve, if it is versioned.)

> Until R7RS-large is done, (scheme comparator) should have some (0 x y) version, which will then be tagged (1 0 0) (or even (7 0 0)) when the large language is finalized.

Any version number in the library name should be the number of the RnRS
edition:

(import (scheme comparator (7)))   ; R7RS
(import (scheme comparator (8)))   ; R8RS
(import (scheme comparator (9)))   ; R9RS
...

RnRS reports should not have minor or patch versions. Why did an
unfinished library get the hallowed "scheme" moniker when R7RS-large is
not even out yet?

I hope everyone realizes the bigger picture here: if SRFI and RnRS prove
unstable to the point that minor versions, pre-releast versions, notes
and patches are to be tracked by users, that undermines the legitimacy
of these institutions. The legitimacy of RnRS and SRFI is already
eroding in the minds of many schemers for similar reasons; we should
clean up our act instead of formalizing the errors of our ways.

> a program has no way to check what version of the SRFI is implemented by a particular library implementation. Some versioning would help here as well but I wasn't able to persuade Arthur.

Persuading the rest of the Scheme community is going to be the hard part.

IMHO best practice is to simply ignore treacherously
implemented/specified procedures in existing SRFIs. Write your own
reduce-right, etc.

Thank you Arthur for sticking to your guns on this issue.