Alexander, I urge you to take a good deal of care with this tracker item and not make any changes lightly.  Take a look at how other languages have dealt with the issue.

Also, consider that "unorderable" may not be the right answer at all.  The most common use of NaNs is as a placeholder for missing data.  Perhaps putting them at the end of a sort is the right thing to do (c.f. was databases do with NULL values).

The other major use for NaNs is a way to let an invalid intermediate result flow through the remainder of a calculation (much as @NA does in MS Excel).  The spirit of that use case would suggest that raising an exception during a sort is the wrong thing to do.

Another consideration is that it would be unusual (and likely unexpected) to have a type be orderable or not depending on a particular value.  Users ask themselves whether floats are orderable, not whether some values of floats are orderable.

I strongly oppose this patch in its current form and think it is likely to break existing code that expects NaNs to be quiet.