PS I think your model would work if SRFIs only documented well-tested
and widely supported features.

Am Mi., 23. Nov. 2022 um 12:10 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> SRFIs *do* get bug fixes.  As is currently the case, they are not frozen.
>
> And I think it is good if errors can be corrected.
>
> SRFIs are not libc, anyway.
>
> Am Mi., 23. Nov. 2022 um 11:42 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
> >
> > > 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?