Because all those other things are either identity types (handles, closures, etc) or are value types where the only possible way to represent them is with a sin

Because all those other things are either identity types (handles, closures, etc) or are value types where the only possible way to represent them is with a single "canonical form." But IEEE754 allows not only NaNs, but also "negative zero" and denormals. Floating-point numbers, in other words, allow for multiple different bit-encodings that represent mathematically equal, but not identical, number values. There are non-canonical forms of the "same" numbers. And programming-language runtimes don't do anything to prevent CPUs from returning these non-canonical numbers; nor do they massage them back into canonical forms upon receiving them. They just end up blindly holding these non-canonical numbers — numbers which, if they ask the CPU if they're equal, they are; but if they look at the bit-patterns and compare those for equality, they're not. > A compiler could use a floating-point-keyed hash table for deduplicating identical floating-point constants. Bad example. A compiler wouldn't want a hash table whose key type is a floating-point number, because that would imply that the hash table is operating using IEEE754 definition of equality via-a-vis key presence collision checking. Rather, a compiler would use a bitstring key type, where the keys are the bit patterns representing either the target ISA's native FP-register encodings of the given floating-point numbers; or the abstract/formal bit-packed form of those floating-point numbers according to IEEE754. The difference between the two is that the latter uses bitstring collation (ordering and equality), not floating-point collation.