I appreciate that being able to add nil to a Set is useful.
All the discussion so far seems to be based upon how to
implement such a change efficiently and safely.

I would like to point out that there is a negative to allowing
nil to be added to a set and as it happens it applies to
every instance of Set I have ever used (at least directly).

A common bug in programs is to have an object set to nil
when the programmer believes the object cannot have value nil,
for example when the programmer has forgotten to initialize a variable.

Currently, if such an object is added to a set an error will occur.  The
programmer must then from this point determine why the object
has value nil.  If sets are modified as proposed no error will occur!!!!!!!!!!!
Since there is a bug, someday the programmer will discover there is
a problem and after some debugging effort determine that the set contains
the element nil (and hopefully recognize that it shouldn't).  (S)he must
then track down the point that nil was added to the set and thus what object
unexpectedly has the value nil.  (S)he then is exactly where s(he) would have
been right away if Sets report an error on addition of nil.

Assuming that nearly all uses of Set do not expect nil to be a possible entry,
I propose the following:

1)  Add Set method  addUnlessNil: object.
This method does nothing quietly if  object == nil.  Otherwise it does
 add: object.

2) Add Set method  addEvenNil: object.
 This method adds nil to the set in some convoluted way that allows
nil to be used
 for the unused entries in the set.

3) Add any supporting methods such as  includesNil  and removeNil  that might
    be needed.

This proposal is of course UGLY for applications needing to add nil to sets.
For example, if one wants to add a collection to a  set then one now needs
methods  addAllEvenNil:  and  addallUnlessNil:.
It does have the following advantages though.
  a) It is totally backwards compatible.
  b) There is no performance penalty except when adding nil to a set.
  c) Situations where nil may be added to a set are clearly marked.

Of course my proposal rests on the assumption that
nearly all uses of Set do not expect nil to be a possible entry.
I believe this to be true.
Even if my proposal is not accepted the assumption implies that whatever
choice is made should be efficient so as not to penalize all the applications
that do not add nil to sets.

An interesting side note is that one could argue that my proposal should apply
to collections in general.  Regardless of how convinced of this one is however,
the fact remains that such a change would break a  LOT OF CODE
(including some of mine) and thus be very difficult to implement in practice.
Regards,

Ralph Boland

-- 
Volume * Density = Mass.
Volume / Density = Intelligence.
The latter equation explains the
essentially equal intelligence of men and woman
and the capabilities of some commonly used operating systems.