rhettinger> Your other tracker item correctly focused on the behavior of
rhettinger> float('NaN') itself,

You closed issue11949 as well, so it won't help.  I disagree that this issue would be resolved by resolving issue11949.  Defining max(nan, x) and nan < x are two different issues.  Quoting Kahan,

"""
Some familiar functions have yet to be defined for NaN . For instance max{x, y} should deliver the same result as max{y, x} but almost no implementations do that when x is NaN . There are good reasons to define max{NaN, 5} := max{5, NaN} := 5 though many would disagree.
"""
-- Lecture Notes on the Status of IEEE Standard 754 for Binary
Floating-Point Arithmetic by Prof. W. Kahan
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

In the same lecture, Prof. Kahan states that nan < x must signal.

My ideal solution would be to make nan < x signal, keep naive implementation of builtin max() and provide symmetric float.max such that nan.max(x) = x.max(nan) = x (nan result would be a valid but less useful alternative.)

This will make float behavior closer to that of Decimal.