Proposed resolution:

This wording is relative to N5014.

1. Modify [compare.type] as indicated:

   template<class T, class U>
     struct type_order;
   

   -2- The name `type_order` denotes a Cpp17BinaryTypeTrait ([meta.rqmts]) with a base characteristic of integral_constant<strong_ordering, TYPE-ORDER(T, U)>.

   -?- If an explicit specialization or partial specialization of `type_order` is declared, the program is ill-formed.

   -3- Recommended practice: The order should be lexicographical on parameter-type-lists and template argument lists.

The recently approved paper P2830R10 proposes to add the new `type_order` type traits to [cmp] (and thus outside of [type.traits]), which has the subtle and most likely unintended effect, that it doesn't fall under the general requirement expressed in [meta.rqmts] p4,

Unless otherwise specified, the behavior of a program that adds specializations for any of the templates specified in [meta.rqmts] is undefined.

and so in principle the explicit allowance specified in [namespace.std] p2,

Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace `std` […]

holds. So we need to add extra wording to the `type_order` specification in [compare.type] to prohibit such program specializations.

This was reported shortly before the Sofia meeting during reflector discussion but seems to be forgotten before the final paper appeared on plenary.

During the reflector discussion two possible ways to solve this issue were pointed out:

1. The most simple one would mimic the wording in [meta.rqmts] p4 quoted above.

2. Instead of introducing just another undefined opportunity to run into undefined behaviour it has been pointed out that we could follow the approach taken by `std::initializer_list` and make the program ill-formed in this case, as specified in [initializer.list.syn] p2:

   If an explicit specialization or partial specialization of `initializer_list` is declared, the program is ill-formed.

I think ill-formed would be better. It shouldn't be difficult for implementations to have special cases that are disallowed.

Given the already existing experience with `std::initializer_list` the proposed wording below therefore follows the ill-formed program approach.