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>.