Comparing NaN with "<=" or ">=" is not significant at all, these operators are not suitable even for a partial order.
Sorting however requires a partial order. The sort function by default assumes that "<=" and ">=" are the logical negation of ">" and "<".
A total order is not always required for sorting (but it is needed if you want a "stable" sort). For a total order, you also need a semantic for "==" (which must be the logical inverse of "!="), something that is also false by default with NaN.
I wonder if the default sort() function should not already have a builtin test for NaN, and a *boolean* parameter saying how we want to sort them (lower than everything by default when it is nil/false, or higher than everything otherwise).
This way no need to specify a custom compare function, it would be implemented natively, may be faster than when using a custom compare function in Lua, and calls to the custom compare functions could be avoided when one of the two values is NaN (and unless you want for a "stable" total order, it can be avoided when both values are NaN; this could optimize for performance in many cases where NaN are very frequent, notably with data selected from database tables with outer joins, i.e. for relations with 0-1 or 0-N cardinality, something that occurs extremely frequently in many apps).
