Item 1. is valid for partial and total orders.
Item 2. is the distinctive definition of total orders.
Everything you say about isless and isequal is true. They need to be aware of eachother. So Item 2. is always true for total orders.
For only partial orders, isless should not be defined, so Item 2. does not apply.
Maybe it would be a good idea to introduce new methods istotalorder(::Type) and ispartialorder(::Type) so the creator of the type has clearly to specify what he wants and it is visible also at runtime, without to lurk at the documentation and guess, if the rules (for isless, isequal, etc.) have been followed.
At the same type it should be clearly documented, which contracts the types of order have to fullfill.
PS. The discussion about Float64 and RFC754 was very interesting to follow. I think, the current implementions of isless and isequal for floating point numbers are consistent. Every NaN is not a number, so the NaN should not destroy the perfect picture.