The case of SRFI 1 is very different from the cases of all other container-type SRFIs affected by the question of linear-update procedures. While SRFI 1 may have initially motivated the idea of linear update procedures in the other container-type SRFIs, the ideal behind SRFI 1's linear-update procedures is special (mostly because SRFI 1 operates on a concrete data type whose implementation is fully exposed to the user).
Thus, in this thread, I have been talking solely about the container-type SRFIs that provide opaque data types. It is just not sensible trying to treat these and SRFI 1 on the same footing. The approach I have been discussing here gets rid of the *linear* update procedures in the container-type SRFIs so that the mutating part of the APIs will look like, say, the mutating procedures of SRFI 125. The question of SRFI 1's linear update procedures is orthogonal to this.
So what is your overall opinion about this new proposal, John? I've tried to make it efficient(ly implementable), that it resolves the various objections against linear update procedures (by Per, Shiro, Wolfgang, and others), that it is simple to implement, and that its API can be used without surprises.