Adding identifiers doesn’t break existing code, but allows new code to be written that’s incompatible with existing implementations. A new code using (srfi 128) assuming extensions doesn’t run on an implementation that provides original  (srfi 128), and there’s no way to avoid it from the code. Only the user gets a mystified by the dreadful “unbound identifier” error. 

If we don’t want the situation like this:
(Import (srfi nnn)
        (srfi mmm)  ; addition to srfi-nnn
        (srfi ppp) ; another addition to srfi-ppp
   …)

Then the newer srfi can include the older one, effectively superseding it. 

The remaining issue is how to amend already voted R7RS-large libraries, and that calls another discussion about versioning. 

On Nov 22, 2022, at 1:00 PM, John Cowan <xxxxxx@ccil.org> wrote:




On Sun, Nov 20, 2022 at 9:15 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
 
Are you particularly concerned about SRFI 162 recommending changes to SRFI 128?  I'm not sure what to do about that.  Technically, it is proposing changes by making a new SRFI, but I see how it isn't a good idea for a new SRFI to change the meaning of an old SRFI in such a way that the meaning of importing the old one changes.

It depends on the meaning of "meaning".  SRFI 162 doesn't recommend an incompatible change to SRFI 128; it only recommends a set of extensions.  In this particular case it is adding new identifiers, so there is an incompatibility in the sense that if you import (srfi 128) you may get more exported identifiers if SRFI 162 is incorporated than if it is not.

On the other hand, if `foo` is a procedure declared in SRFI X that supports two arguments, and in SRFI Y the procedure 'x' supports two or three arguments, there is a technical incompatibility in the sense of R6RS but not in the sense of R7RS.

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.

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.