I think a better reasoning is that NaN does not have a single binary representation but in software, one may not be able to distinguish them.
An f32-NaN has 22 bits that can have any value, originally intended to encode error information or other user data. Also, there are two kinds of NaNs: queit NaN (qNaN) and signalling NaNs (sNaN) which behave differently when used in calculations (sNaNs may throw exceptions).
Without looking at the bits, all you can see is NaN, so it makes sense to not equal them in general. Otherwise, some NaN === NaN and some NaN !== NaN, which would be even more confusing.
I don't think that logic quite holds up because when you have two NaNs that do have the same bit representation, a conforming implementation still has to report them as not equal. So an implementation of `==` that handles NaN still ends up poking around in the bits and doing some extra logic. It's not just "are the bit patterns the same?"
(I believe this is also true for non-NaN floating point values. I'm not sure but off the top of my head, I think `==` needs to ignore the difference between positive and negative zero.)
> NaN === NaN and some NaN !== NaN
In julia NaN === NaN evaluates to true but NaN === -NaN evaluates to false. Of course, NaN == NaN evaluates to false. I think it makes sense that in principle === looks at bit representations, but cannot think of any reason === is useful here, unless you want to encode meaningful stuff inside your NaNs for some reason. It reminded me of this satirical repo [0] discussed also here [1].
[0] https://github.com/si14/stuffed-naan-js [1] https://news.ycombinator.com/item?id=43803724