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?