Wouldn't it be simpler just to fork from 4.2? Making immutable pairs not-really-immutable shouldn't actually break any existing PLT-based code, since that code won't modify them. ^_-
It might break some low-level optimizations in PLT Scheme itself (which could be fixed in the forked version), it might break compatibility with other projects that dig into the PLT code, and it might annoy some library writers who really didn't want careless users to shoot themselves in the feet or expose security holes, but that's all the trouble I can think of offhand.
Breaking the PLT Scheme optimizer by mutating pairs it thinks are going to be immutable and then going in and figuring out which optimizations to fix doesn't sound very simple to me... but, assuming that it was easy to do, what does starting from 4.2 do for us?
I guess I just see "Take the newest MzScheme and implement not-so-immutable conses again" as a conceptually easier task than "Take the fork and implement feature A and feature B as inspired by the newest MzScheme." Of course, the more objections we have to MzScheme changes, and the more features of our own we want to include, the harder this becomes.
I guess I never noticed that the existing ++ operator could take a second argument, sorry.
However, the *= and /= operators are still very useful, and it would be very cool if a simple ssyntax could make it general to all single argument functions, or at least functions in which the first argument is the one being modified/extended. Good examples would be += as applies to alists and tables, and things like cut or sort.
Is there a reason that you can't append an atom to a list with '+ or '++?
