>> Exactly. It can happen with other kind of dictionaries as well. And class checks would not enough:
>>
>> d1 := PluggableDictionary new.
>> d2 := PluggableDictionary new equalBlock: #==.
>> d1 at: 'test' copy put: 4.
>> d2 at: 'test' put: 4.
>> {d1 = d2.
>> d2 = d1}
>>
>> So, performance goes down in some cases, but I guess we agree on #= has to be symmetric.

For simple value types, yes, we should be able to make that
assumption, but symmetry of equivalence starts to break down for
objects as complex as a Dictionary..

> We can speed up some cases if the dictionaries can tell if #= is guaranteed to be symmetric
> when they have the same class.
>
> But #hash still uses species, that means, we can have a Dictionary and an IdentityDictionary to be equal, but with different hash.
>
> s := 'a'
> ed := Dictionary with: s -> $a.
> id := IdentityDictionary with: s -> $a.
> { ed = id. id = ed. ed hash = id hash } "->  #(true true false)"

Equivalence of complex objects is always a "loose" definition, of
which there can be several.  Additional API like #hasEqualElements:
(of SequenceableCollection) could be added as needed to accomodate
other application needs, but we only get ONE particular implementation
which can also be suitable for use in HashedCollections, because they
send #=.  Changing it should be really scrutinized.

I'm wondering if Levente could get by with an app-specific equivalence
check without needing it for use in HashedCllections?  Seems like a
lot of the #= in the system require class or species equivalence, a
few allow isKindOf:, but only one or two allow #is message response.
I'm wondering now if those last kind are ill-advised...

BTW, with this change, I guess we're now somewhat inconsistent with Set,

| ed id |
ed := Set with: 'a' copy.
id := IdentitySet with: 'a'.
{ ed = id. id = ed }   " #(false true)"

My production app is going to be punished by Levente's change,
unnecessarily.  I think we should consider an alternative like adding
#hasEqualElements: for your app...