Proposed resolution:

This wording is relative to N4878.

1. Modify [thread.thread.id] as indicated:

   strong_ordering operator<=>(thread::id x, thread::id y) noexcept;
   

   -6- Let P(x, y) be an unspecifieda total ordering over thread::id as described in [alg.sorting], unspecified except that P(x, y) is false when x and y both represent the same thread of execution, or when neither represents a thread of execution.

   -7- Returns: strong_ordering::less if P(x, y) is true. Otherwise, strong_ordering::greater if P(y, x) is true. Otherwise, strong_ordering::equal.

[ 2021-03-12; Reflector poll ]

Set priority to 3 following reflector poll.

[thread.thread.id]/5-7 specify the behavior of == and <=> for std::thread::id:

bool operator==(thread::id x, thread::id y) noexcept;

-5- Returns: true only if x and y represent the same thread of execution or neither x nor y represents a thread of execution.

strong_ordering operator<=>(thread::id x, thread::id y) noexcept;

-6- Let P(x, y) be an unspecified total ordering over thread::id as described in 25.8.

-7- Returns: strong_ordering::less if P(x, y) is true. Otherwise, strong_ordering::greater if P(y, x) is true. Otherwise, strong_ordering::equal.

"Unspecified total ordering" provides too much freedom, since it does not require that !P(x, y) holds when x and y both represent the same thread of execution or both represent no thread of execution. A conforming implementation could return strong_ordering::equal from <=> for a pair of thread::id values for which == returns false. We should guarantee consistency of == and <=> for thread::id to preserve sanity of the programming model.