I spent much of last night coding up and testing #collect:into:.
(Why so much time?  Because of the need to check all versions of
#collect: in the system to make sure I wouldn't break anything.)

On the way, I found a number of interesting things.
For example, Path> >collect: and Path>>select: 
were totally broken in Squeak 3.0 and 3.2.  I have to assume that
nobody ever used them.  The change set I am developing fixes them.

One of the nasty things when you are replacing parts of the core
is that you have to be *very* careful about the order you do things.
I discovered this the hard way, meeting the emergency evaluator for
the first time (and the second and the third and ... sigh).

We have
   Collection                > >collect:
     SequenceableCollection  > >collect:
       OrderedCollection     > >collect:
         SortedCollection    > >collect:
and you have to
(1) plug in the rest of the collect:into: framework,
(2) replace Collection> >collect:
(3) remove SequenceableCollection> >collect:
(4) remove OrderedCollection> >collect:
(5) remove SortedCollection> >collect:

If you do step (4) before doing step (3), it's emergency evaluator time.

Once I realised what I was doing wrong, I started up a fresh system,
loaded the new methods, and then did (2..5) in the right order.  Hooray!
It all worked.

So I saved the lot as a change set, started up a fresh system,
loaded the change set, and HELLO EMERGENCY EVALUATOR!

Reason: the change set did not save the removal steps in the order I did
them, but in ALPHABETIC order!  That moved step (4) before step (3) and
disaster predictably struck.

Q1:  Why are change sets saved in alphabetic order rather than
     chronological order?  It seems obvious that this is likely to
     break change sequences.

Q2:  Is there any way I can tell change management to use chronological
     order instead?

Q3:  At the moment, I'm dealing with the problem by manually shuffling
     the removal directives whenever I save a new version of the change
     set.  Is there a better way to do this?

Q4:  I'd like the change set to be usable in 3.0, 3.2, and 3.4.
     Is it OK if a change set file contains directives to remove methods
     that don't exist?  How do I make one remove a method from a _class_
     that might not exist in some version?