I think that if Liskov's principle is respected, a shouldn't care about b not being of the same class. Rather, b could rightfully complain about the colorless t

I think that if Liskov's principle is respected, a shouldn't care about b not being of the same class. Rather, b could rightfully complain about the colorless thing it is compared to - although it wouldn't be wise to do so. Inheritance is just a scapegoat here. Changing the definition of the equality in the subclass is probably a design mistake (because it's confusing and error prone). The core of the problem is that, contrary to trivial things like integers, with complex objects one may be interested in defining different equivalence relationships in different parts of the same application. If everyone insists to use the = sign to note "their" equality, inevitably there will be conflicts. So in a way, not allowing to highjack the = operator (or == depending on how the language expresses assignment) and keep it for identity (i.e. address equality) could actually be the sane approach. In your example, renaming "equals" to "hasSameCoordinates" wouldn't be bad practice, I believe.