> If on the gripping hand we are to say that *any* change to a SRFI
> requires a marker of incompatibility including bug fixes, then we need a
> completely new SRFI number for each fix, in which case we cannot import
> both SRFI M and SRFI N.  If we are to avoid that, we must have libraries
> (srfi 128), (srfi 162), and (srfi 162 butnot 128).  Once we get up to
> five possible bug fixes, we end up with 32 libraries.

Depends on the nature of the bug. If the buggy facility is useless to
everyone, it's probably fine to fix the bug in the spec. Implementations
will upgrade eventually (after a several years), and conservative code
can avoid using the facility until then.

If the buggy behavior is commonly and successfully worked around, and
the bug fix would break the workarounds, it's better not to fix the bug.

> Using features makes things worse: we need a new feature name for every
> bug fix, and we need a mechanism to say which features a given library
> supports.

Agreed. Empirically, several Scheme implementations' feature lists are
already starting to fill up with stuff that should probably go elsewhere.