>
> The SRFI document refers to mutability in several places, yet the only
> mutating operations defined are linear updates. Linear update, as it is
> currently defined is "optional", ie. linear update operations are free
> to return fresh data structures. Thus linear update is little more than
> an optimization technique based on hints from the user, and the SRFI
> does not cater for mutable collections.
>
> Many Schemes have mutable collections (e.g. hash tables are usually
> defined as mutable collections) and there is a substantial code base
> that relies on this mutability. Such code could not be easily modified
> to take advantage of this SRFI, which seems unfortunate.
>
> Mutation is evil in most cases, but it can be useful. That's why Scheme
> has set!, set-car! and set-cdr!. So can we please have mutable collections.

It seems that adding language that allowed compatible SRFI's to declare
whether they are linear-updating or purely side-effecting may solve
this problem.  In the latter case, the update procedures would
still return the input collection, allowing code written straight to
SRFI-44 to still function, but code written specifically to the child
SRFI would be allowed to ignore the return value.  For example, the
following snippets would be legal, and both would return the same value:

(define h (make-hashtable eq?))

(let* ((h1 (dictionary-put! h 1 'a))
       (h2 (dictionary-put! h 2 'b)))
  (collection-fold-keys-increasing h2
    (lambda (k ls)
      (values #t (cons k ls)))
    '()))

(begin
  (dictionary-put! h 1 'a)
  (dictionary-put! h 2 'b)
  (collection-fold-keys-increasing h
    (lambda (k ls)
      (values #t (cons k ls)))
    '()))

	Scott