I think you’re overindexing on copy-on-write, but I admit I’m having a hard time thinking of when “definitely unequal” would be worth knowing. Abstractly, I assume every optimized Equatable implementation would start with the O(1) checks anyway, both positive and negative*, and then fall back on checks that require O(N) work; thus, the purpose of separating the O(1) check is if you would rather do something different to avoid falling into the O(N) case. Or, as Ben put it in the previous thread:
The motivation being, an observer might be about to do some linear operation anyway when values have changed, and that linear operation is fairly similar in effort to an equality check in cases of false change notifications, so they might as well do it even when nothing has changed rather than pay the price of first checking for definitive inequality, then performing that work.
Consequently, if there were a use for “definitely unequal”, it would be that the observer would do expensive work if the objects are equal, and it’s okay to do that work if the objects are inequal, but we’d skip it if we could. I can contrive some cases like that by making the object some kind of key: if the key is one of the ones I care about, I will use it to do an operation on the value associated with it. Only…keys are usually cheap enough to compare fully, and even if they’re expensive it’s rare that the cost of the check will outweigh whatever work you might do with them.
Still, even with that I think michelf is right that the tri-state makes it more likely people will use the method correctly. It also makes it much simpler to say “nil is always a correct response for this method, if a bad one”, just like “not hashing anything is always a valid hash(into:), if a bad one”.
* @David_Smith reminded me of an infamous case where this is not true: memcmp does not check whether you gave it the same pointer in both arguments, the idea being that if you need to optimize your call to memcmp, the caller should be the one to check pointer equality, because that saves the overhead of a function call!