TL;dr: If you just want to see my recommendations 1-4, jump to the bottom.
A linear-update procedure is one that may or may not mutate one or more of its arguments. SRFI 1 says:
Many procedures in this library have "pure" and "linear update" variants. A "pure" procedure has no side-effects, and in particular does not alter its arguments in any way. A "linear update" procedure is allowed -- but not required -- to side-effect its arguments in order to construct its result. "Linear update" procedures are typically given names ending with an exclamation point. So, for example, (append! list1 list2) is allowed to construct its result by simply using set-cdr! to set the cdr of the last pair of list1 to point to list2, and then returning list1 (unless list1 is the empty list, in which case it would simply return list2). However, append! may also elect to perform a pure append operation.
[...]
What this means is that you may only apply linear-update procedures to values that you know are "dead" -- values that will never be used again in your program. This must be so, since you can't rely on the value passed to a linear-update procedure after that procedure has been called. It might be unchanged; it might be altered.
Now if the underlying data structure is mutable, a linear-update procedure is just a mutation procedure, and if it is immutable, the linear-update procedure is just a functional update procedure. So I think the case for linear-update is strongest when the SRFI-specified interface is meant to bridge a mutable and an immutable implementation.
A particularly good example of this is SRFI 185, which bridges between Schemes that can support SRFI 118 (adjustable-length strings) like Kawa and perhaps STklos, and Schemes which cannot (the great majority), in which case the string argument must be copied, but a common interface can be provided.
So here's the list of relevant SRFIs:
SRFI 1 Lists
SRFI 3 List Sets
SRFI 14 Character Sets
SRFI 32 Sorting
SRFI 44 Miller Collections
SRFI 57 van Tonder Records
SRFI 113 Sets and Bags
SRFI 132 Sorting
SRFI 146 Mappings
SRFI 153 Ordered Sets
SRFI 185 Linear Adjustable-Length Strings
SRFI 209 Enum Sets
SRFI 217 Integer Sets
Discussions and recommendations for specific SRFIs follow (I believe this list is complete):
SRFI 1: Linear update is long-standing, and while the sample implementation uses mutation, the Chibi implementation does not (for code compactness).
Recommendation: Maintain linear update.
SRFI 3: Withdrawn in favor of SRFI 1. No recommendation.
SRFI 14: The sample implementation is quite limited: it supports Latin-1 only, and it uses a 256-element vector whose mutability shows through. The Chibi implementation is built on the Chibi implementation of integer sets, which are also mutable.
However, it would be trivial to implement 14 on top of 217 or (better) of SRFI 224, Integer Mappings, which have immutable sample implementations. An implementation based on a #(start, end, start, end ...) representation, where containment can be established by binary search, would also be naturally immutable. Linear update bridges these various implementations.
Recommendation: Maintain linear-update.
SRFI 32: Though still common, this has been superseded by SRFI 132. No recommendation.
SRFI 44: A framework for collections. It has not had widespread uptake, has not been built on further, and generic functions and/or type classes will be able to do the same things. No recommendation.
SRFI 57: A set of extensions to SRFI 9 / R7RS records that provides linear-update operations for the fields. This also has had little uptake, though I believe it should be looked at further when discussing single-inheritance records. No recommendation.
SRFI 113: The sample implementation is based on SRFI 125 hashtables, which are mutable. We currently have no immutable counterpart, as 153 was withdrawn (see below).
Recommendation: If and when we have immutable sets, change linear-update procedures to mutable ones.
SRFI 132: This is about algorithms rather than data structures. Only two procedures, list-sort and list-stable-sort, are linear-update: the others are either functional or mutational. The sample implementations are mutational.
Recommendation: Maintain the existing limited use of linear update.
SRFI 146: The sample implementation is immutable. No other implementation seem to be in use at present. If limited to immutable implementations, this would pair with SRFI 125 (inherently mutable).
Recommendation: Eliminate linear-update procedures completely.
SRFI 163: Currently withdrawn for lack of an implementation.
Recommendation: Create an implementation on top of SRFI 146, removing linear-update procedures completely. This goes along with the recommendation for SRFI 113.
SRFI 185: Discussed above.
Recommendation: Maintain linear update.
SRFI 209: Sample, Chicken, and Chibi implementations are all mutational. Since enum types are usually not very big, copying enum sets is feasible.
Recommendation: Change all linear-update procedures to mutational ones.
SRFI 217: Sample implementation is immutable.
Recommendation: Eliminate linear-update procedures completely.
TL;dr recommendations for change:
1) Make SRFI 113 mutable and revive SRFI 163 as its immutable counterpart.
2) Make SRFI 146 immutable; SRFI 125 unchanged serves as its mutable counterpart.
3) Make SRFI 209 mutable.
4) Make SRFI 217 immutable.
How much, if any, of this can be done with PFNs is an Arthur question. In any case should keep some !-marked functions in SRFIs 146 and 217 deprecated for backward compatibility rather than removing them altogether, but they will work the same as their non-! counterparts.