Two comments.

First, the reason Set's cannot contain nil is because nil is used
internally as a placeholder.  This is a bad thing IMHO and it would be
better to allow nil.  At any rate, since dictionaries always use
assocations in the non-empty slots, then hey do not have the same
problem Set's do and so it would seem reasonable that they can have nil
as a key.  (Though, alas, this means that the current #keys method runs
into problems.  Ack!)  I'd prefer that we move in the direction of
supporting nil in dictionary's and set's, because there is no
fundamental problem with it.  (Set could have an instance variable
holdsNil that specifies whether nil is in the set!  Or, Set's could use
a different place holder than nil; they could do "Object new" to create
a unique placeholder object.)

Second, on the issue of WeakKeyDictionary keys, note that the keys are
held by weak references.  Thus, are you certain that in this code from
your changeset that the key will not disappear between the check for nil
and the evaluation of the block?

	super associationsDo: [ : eachAssoc | eachAssoc key ifNotNil: [ aBlock
value:
eachAssoc ] ]

If ifNotNil: has been inlined, then I would think the block might lose
access to the key.  You could test this by having a key that becomes
garbage, then call associationsDo:, and then have aBlock run a garbage
collection as the first thing it does.  Anyway, it seems safer to make a
hard reference to the key just to be sure, something like:

	:eachAssoc | 
	| key |
	key _ eachAssoc key.
	key ifNotNil: [ aBlock value: eachAssoc ]
	
Now, the "key" variable will keep the key from disappearing until aBlock
is through evaluating.



-Lex