> I fail to see how what you said relates to what I had said.

SRFIs are like libc or POSIX in the sense that there's a spec with
multiple implementations. It's inevitable that the spec writers can't
get everything right, and if there are "old" and "new" versions of the
spec, both will exist in the wild simultaneously.

libc functions are not versioned because that would be too complicated.
It would become a maze of #ifdef's or you'd put version numbers in the
function names themselves.

The solution with SRFI, as with libc, is to be conservative. And when we
inevitably mis-specify something, advise users to avoid those corners of
SRFIs, just as broken POSIX/libc functions are avoided.

With RnRS, the above concerns apply more strongly still. RnRS is
versioned, but as a social custom (as with POSIX) new version should
only add stuff and not deprecate anything that hasn't fallen out of use.

There are a dozen places one can publish fast-moving, experimental
libraries that receive the latest bug fixes and performance updates. Why
turn SRFI into one when it was designed to do the opposite?