It would take a compelling argument to make me accept that "Yes, I shouldn't do that", but I don't assume that such a compelling argument doesn't exist.

Probably not what you want to hear, but IMO Math modules should treat NaN in accordance with the following paragraphs:

Floating point operations other than comparisons normally propagate a quiet NaN (qNaN). Floating point operations on a signaling NaN (sNaN) signal an invalid operation exception, the default exception action is then the same as for qNaN operands and they produce a qNaN if producing a floating point result.

A comparison with a NaN always returns an unordered result even when comparing with itself. The comparison predicates are either signaling or non-signaling, the signaling versions signal an invalid exception for such comparisons. The equality and inequality predicates are non-signaling so x = x returning false can be used to test if x is a quiet NaN. The other standard comparison predicates all signal if they receive a NaN operand, the standard also provides non-signaling versions of these other predicates. The predicate isNaN(x) determines if a value is a NaN and never signals an exception.

Which I interprete to mean that: given one or more NaN values to compare, equality operators should return false if they are of the non-signalling variety and raise an exception if the are signalling.

As (TTBOMK), there is no concept of non-signalling/signalling NaNs anywhere else in Perl, I think there are 3 possibilities for Math modules:

1. Opt to implement non-signalling NaNs.

   Any equality operator involving a NaN value, and any other value including NaN, +/-inf or an numeric value returns false.

   To allow the programmer to detect when they are dealing with NaN value, you either a) provide an isNaN( $x ) function; or b) allow the (somewhat bemusing) suggestion above of using die "We got a NaN\n" unless $x == $x;

2. Opt to implement signalling NaNs.

   Any operation involving (being passed, rather than resulting in) a NaN value raises an exception.

   This at least forces the programmer to deal with the possibility.

3. Make it configurable.

   Offer both modes of operation and let the programmer choose.