Why does IEEE 754 reserve so many NaN values?

The IEEE-754 standard defines a NaN as a number with all ones in the exponent, and a non-zero significand. The highest-order bit in the significand specifies whether the NaN is a signaling or quiet one. The remaining bits of the significand form what is referred to as the payload of the NaN.

Whenever one of the operands of an operation is a NaN, the result is a NaN, and the payload of the result equals the payload of one of the NaN operands. Payload preservation is important for efficiency in scientific computing, and at least one company has proposed using NaN payloads for proprietary uses.

In more basic terms, a NaN doesn't carry any useful numerical information, and the entire 32 bits must be reserved anyway, so the unused bits in the significand would be otherwise wasted if there were not a payload defined in the standard.

According to this series of notes by William Kahan, one of the designers of the IEEE-754 format, the use of multiple NaNs was intended to let hardware fill in information about what triggered the NaN in the first place so that computations that would end up resulting in NaN could run to completion and then allow the programmer to write code to analyze what had gone wrong:

IEEE 754's specification for NaN endows it with a field of bits into which software can record, say, how and/or where the NaN came into existence. That information would be extremely helpful for subsequent “Retrospective Diagnosis” of malfunctioning computations, but no software exists now to employ it. Customarily that field has been copied from an operand NaN to the result NaN of every arithmetic operation, or filled with binary 1000...000 when a new NaN was created by an untrapped INVALID operation. For lack of software to exploit it, that custom has been atrophying.

So it seems like this was intentional and left unspecified so that different systems could handle things differently. In retrospect, it seems like this never really ended up happening, but it seems like a reasonable idea!

There is likewise a payload for 64 bit floating point numbers as well, with ~10^15 possible values. Unfortunately, implementations diverge as to how the payload should be transferred between 32 and 64 bit floating point numbers and back again, i.e. whether you preserve the most significant or least significant bits. Since payload treatment is machine specific, you need different code to deal with payloads on different machines.

I wouldn't worry too much about which NaN payload is propagated after a binary operation. NaNs are exceptional values that occur with low probability, and the probability of getting 2 of them is unlikely.