I think we both agree, that Comparable and equals are not a perfect fit to express all the operations we want to do with them. One problem here is if the given types differ. now javadoc for Comparable says
This interface imposes a total ordering on the objects of each class that implements it. This ordering is referred to as the class's natural ordering, and the class's compareTo method is referred to as its natural comparison method.
This natural order implies that the objects compare are of the same class in some sort of way or that the operation will cause an exception. Throwing an exception means the operation is not defined, so we are talking here about a partial function when you look at all possible values.
the goal is to get a function where the signum of x.compareTo(y) is the revers version of y.compareTo(x). So if x.compareTo(y) throws an exception, y.compareTo(x) should do the same or you break symmetry big times. That includes for example that x.compareto(null) in java has to throw a NPE, because null.compareTo(x) would do that. This also implies that if x and y are of different types and if x does not know the type of y in any way, that x.compareTo(y) must throw an exception, since both types are not comparable. Which then again implies that y.compareTo(x) must throw an exception too, even if y would know x. And that is a difference from equals, which can always return false then. And the common way to ensure this is to throw a ClassCastException.
So even if the javadoc does not say you have to use the same type, if you want to fulfill their implications, you have to do that. In the jdk source you will most probably not find an example that allows you to compare two instances of different unrelated classes. I mean they had their reason to define Comparable as "interface Comparable<T>"
Now or your patch... true, compareTo might throw a ClassCastException, but who ensures, that is not due to a programming error in a method called from there somewhere deep down the stack? In fact we don't know if the exception is thrown as part of the contract for Comparable, or because of a different reason. So the danger is that we hide a problem, leading to endless debugging sessions and angry users later.
Also your assumption may be correct, that most code won't be affected by this change, but only if they don't depend on the exception being thrown. So your patch builds on what you expect others not to do?