It sounds more like the designer does not understand what NaN is. The whole point of NaN is that it propagates through all operations so making (Nan == Nan) == true defeats that purpose.
In that case, making (NaN == NaN) == false also defeats it. false isn't NaN either. If true or false propagates out of a function whose inputs are NaN, NaN has failed to propagate.
With that logic, you could say making (1 == 1) == true is wrong, because 1 isn't true.
> If true or false propagates out of a function whose inputs are NaN, NaN has failed to propagate.
He meant Nan propagates through calculation operation, not comparison operation. As in, result of calculating Nan + 1 is NaN.
So if you have "A = NaN" and "B = A + 1", you have the situation that both A and B is NaN but A does not equal B.
1 == 1 isn't erroneous. Producing a boolean is the type of the operation: number x number -> bool.
(bool's domain could be extended with additional "nonbool" values, which are produced if some of the operands to a numeric comparison are not numbers.)
> calculation operation, not comparison operation
What's the difference? It's all computation. The comparison calculates a boolean result.
> As in, result of calculating Nan + 1 is NaN.
No it isn't. Proof:
NaN + 1 == NaN // yields false
What would make sense would be to allocate a new NaN, so that it is legitimate that NaN + 1 != NaN. Neither side is a number, but the express different, individual ways of not being a number through their different identities. And the "isnan(X)" predicate tests whether X is an element of the set of all NaNs.
If that's not palatable, throw exceptions: don't allow NaN + 1 (why allow addition on "not a number"? Why even allow "not a number" to be stored into a variable of number type, in a static language?)