A general comment on all of the new `__eq__` methods: Use of the corresponding objects in sets or as dict keys would be undefined behavior. Quoting from http://docs.python.org/2/reference/datamodel.html#object.__hash__ : 

> If a class defines mutable objects and implements a `__cmp__()` or `__eq__()` method, it should not implement `__hash__()`, since hashable collection implementations require that a object’s hash value is immutable
> ...
> Classes which inherit a `__hash__()` method from a parent class but change the meaning of `__cmp__()` or `__eq__()` such that the hash value returned is no longer appropriate (e.g. by switching to a value-based concept of equality instead of the default identity based equality) can explicitly flag themselves as being unhashable by setting `__hash__ = None` in the class definition.

So, should all these classes also set `__hash__ = None` to just forbid their use in hashable collections? This is probably not a big deal, especially since ComponentSet should be usable in most situations where you'd want a set anyway. 

Alternatively, would it be possible to make all of these objects immutable and thus hashable? This might actually have a lot of other positive side-effects in model/macro code, but would be a pretty big breaking change. We'd need to come up with a new way to achieve the copy-and-modify pattern that macros and such often use.