The issue with the first semantics is that it will be very surprising and will not be compatible with all the existing codes that only use == instead of a == followed by a call to equals(). The issue with the second semantics is that it's an unbounded computation, shaking the Java performance model everybody has in mind by moving == from one of the fastest operation to a potentially very slow operation.
I'll just add a few more points to this. (All of these amount to: you have a point, but please, let's not overstate it.)
1. Java users are used to unbounded equality computations; calling .equals() on a List or Map does a ton of work, and nobody is shocked by this. What's potentially surprising is to see this behavior behind `==`. That's the new bit.
2. Generic code that only uses == and not .equals() is generally broken, so I am not too bothered by this "compatibility" concern.
3. We don't actually know what the performance impact is. (And for common cases, it will likely be small.) We can speculate, but better to gather some performance data before we write off this approach. There will be a prototype soon that we can play with.
