Can I give a reference?�� Well, I did: the ANSI Smalltalk standard.
Specifically, section 5.7.8.2, the refinement for <sequenceReadableCollection>
Numbers are governed by section 5.6.7.1, which requires numbers that are
compared for equality to be converted to a common representation, which
in this case requires (sigh) integers to be converted to floats.�� With
that definition it is possible to find integers x z and a float y such
that x = y and y = z are true but x = z is false, which is a very bad
thing.�� My Smalltalk tries to be ANSI conformant, but some things are
just too broken to live with, and that's one of them.�� (The rule should
always be to convert in a way that loses no information.)
It may well seem strange to you, but "equivalence" (#=) in Smalltalk
is not coupled to "ordering" (the Magnitude methods) and never has been.
For example, #= compares the characters of strings, which are equal iff
they have the same codepoint.�� But #< and the other magnitude methods
use an "implementation-defined" collation order, which could, for example,
ignore alphabetic case.�� So it would be entirely consistent with the
standard and historic practice to have 'A' <= 'a' and 'a' <= 'A' but
'A' ~= 'a'.�� This is not merely a theoretical possibility; I just tried
it in GNU Smalltalk.
There was a serious historic bug in many Smalltalks where
'a' = #a was true (using string comparison) but
#a = 'a' was false (using identity).�� This may well be
why the standard insists on the classes (not the species)
being the same, to ensure that <string> = <symbol> is
consistent with <symbol> = <string>.