I can’t tell you about history, but I can throw in my 2 cents on why this restriction may or may not be sensible.
First note that in mathematical terms, the terminology “total order” or “partial order” both only are used to describe binary relations on a single set, i.e. always corresponding to the situation where the left-hand-side and right-hand-side types are the same. So that terminology is irrelevant for discussing this question.
If Eq is interpreted as a notion of “mathematical equality” (not just an “equivalence relation”), then a “partial order” corresponds to T: Eq + PartialOrd, and a “total order” corresponds to T: Ord. That’s a lot of conditions to get a good correspondence, and PartialEq is completely out of the equation nonetheless, so let’s not focus too much on mathematical terminology.
In terms of actual documented requirements, the only thing that differentiates T: Eq from T: PartialEq<T> is the additional requirement that x == x should be true for all x.
Now, imagine we had some sort of T: Eq<U> trait. What would it’s additional requirement over T: PartialEq<U> be when T and U are distinct types? It cannot be x == x, because x cannot be both of type T and U at the same time. The only option I can think of would be to have no additional requirements at all. Possibly that seemed to use-less of an approach, so it wasn’t followed?
For Eq and PartialEq in isolation, Eq with different left-hand-side and right-hand-side types is not very useful. On the other hand, since Ord requires Eq, restricting Eq to operate on a single type transfers to Ord as well. And for Ord, there is an additional requirement that still makes sense even when the types are different, i.e. that partial_cmp never fails.
So I conclude that there might indeed be some sense in the idea of generalizing Eq to have a Rhs parameter, too. One reasonable extra requirement for Eq itself over PartialEq that I just thought of could probably be that T: Eq<U> implementations are expected to only exist when T: Eq<T> and U: Eq<U> implementations exist as well. Similarly for Ord, I guess… I’m not a big fan of these “such and such implementations must exist” requirement in the first place, because it’s unclear (to me) how exactly they should be upheld, but that’s a separate discussion.
In case the question is whether the extra Rhs parameter could be added to Eq now, i.e. whether that’s a breaking change, on first thought, I would say … probably not breaking!? … unless I’m missing something.