The full documentation of the "--general-numeric-sort" option of
{sort} says that NaN values are sorted "in a consistent but
machine-dependent order".
This is not good. The point of the IEEE floating-point standard was to
make the results of floating-point computations be independent of the
platform or implementation.
Please consider extending that goal to the handling of NaNs by {sort}.
That it, all flavors of NaN (determined by their char tails, as
parsed by {strtod}) should be treated as equal.
The fact that different flavors of NaN have distinct binary
representation is not an excuse to sort them as distinct, since the
same is true of +0 and -0, which "general-numeric" sort already treats
as equal.
As a separate suggestion, please consider having {sort} abort with an
error message if any field that is supposed to be sorted with
"general-numeric" is not a valid {double} value, or has some leftover
chars that are not parsed by {strtod}.
Whether these solutions are accepted or not, please change the manpage
explanation of "-g"/"--general-numeric-sort" to say, at least, "the
field is parsed as a double-precision (64-bit) floating-point number
and sorted by its numeric value".
Thanks, and all the best,