> I think the main point is that this is not how it has always been
> handled.  Just a few examples:
>
> - The SRFI 1 erratum of 2022-10-22, while very reasonable, is outside
> the narrow scope painted above.
> - How can a program know whether a particular implementation of SRFI
> 116 uses SRFI 114 or SRFI 128 comparators?  If we take the above
> strictly, PFN #2 must be ignored and implementations must continue to
> use SRFI 114 comparators.
> - The SRFI 124 erratum is also outside a narrow scope of fixing blatant errors.
> - PFN #1 and #3 of SRFI 128 would have to be ignored by implementation
> in the strict sense.
> - The order of vector-cumulate was later changed in SRFI 133
> - ... ... ...

You have a tendency to believe that precision will solve the world's
problems. While precision has its place, I've been trying to hint that
it causes as many problems as it solves.

Sometimes we should take a big hammer to a problem. It doesn't pay to be
precise about details when the big picture is veering toward absurdity.

Library design is as much a social problem as a technical one. Social
problems are solved by authority. Authority comes from confidence, which
is eroded by amendments and course corrections to what one did before.
SRFI 116 switched from one kind of comparator to another. Are we to
believe that the right kind of comparator has now been found? I have my
doubts.

I don't know whether you listen to jazz, but the landmark albums were
recorded with very few takes and edits. A Love Supreme was done in one
day. The result is canonical, not Platonic. That's the spirit of SRFI.
That's why SRFI 1 is so widely respected and relied upon. Nobody thinks
it's God's word on lists; everybody uses it.

There's a place for publishing things that aren't landmarks, but that
inherently gives rise to different process requirements. I'll propose a
big hammer in a new thread.

> I am not against declaring that SRFIs should be immutable in principle
> once finalized, but then we should pull it through and make publishing
> revisions (under new numbers) of SRFIs a simple and straightforward
> task.

It's intentionally difficult so that people don't submit incremental
improvements to earlier stuff, but submit them in big batches instead.