>
> That's absurd. The point of the semantics of comparisons is so that it
> behaves a certain way *by default*.
>

All I tried to do was start writing a predicate.
By default, how do you expect an MP::Integer to behave? Like an integer.
std::partial_ordering because it supports NaN. Could that happen with just
operator <=>? No. Because.
What happens now? I end up writing a 3-way called "Compare" that returns
either std::partial_ordering or something isomorphic, and then using it to
hand-roll all 6. In semi-readable code, that amounts to 12 lines.
operator <=> didn't help at all. std::x_ordering is the same as thousands
of other relationship enums written, and the behavior is now the same as an
int.

How can I convey that MP::Integer has std::partial_ordering category?

I guess I'll do this:
https://godbolt.org/z/7r9hP9hn8

SLOC-wise, this is exactly the same as having a public ordering_category
alias.
Semantically, it is exactly as error-prone.
So, I guess decltype( a <=> a ) and make assumptions.

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1185r0.html

The central example in the above paper is what I'd call a cludge, but I'll
try to work with it.

So, say we can't re-write <=> to be efficient. We want to use a more
efficient operator ==.
If that is visible in the same TU, report it as ambiguous. operator <=>
already provided operator ==.
Approach the new code differently (since it is what generated said error),
and explicitly use a new fast_vector_cmp().
We have a bunch of stuff that assumes operator == with vector<> in a
library. What led to this?

This reads like a problem with development practice enabled by what should
have been considered a language defect.
Instead of addressing said defect with an error, make <=> unintuitive
up-front and no longer helpful.

Water down the drain, but anyway:
It is straightforward to extrapolate what <=> does in a TU, assuming it was
6 declarations in one.
What would happen if two operator== appeared in the same TU? An error.
What do we have? An unintuitive almost-solution.

Thanks to all participants for their time and contributions.