All of this would be valid, except that value classes still pretend that their fields can be private.
This also has huge implications in a language that emphasises dynamic loading like Java. And it also flies in the face of all of the pretenses that ABI compatibility is sacrosanct and no feature that breaka it can be considered, that the design team often touts.
Why pretend? "private" on value types just means nothing to see here except when you happen to be one of the functions conveniently namespaced with the struct.
But I'd say that GP's complaint about inequality leaking makes no sense anyways, because what could be more unequal than different implementation, or different internal state implying different behavior down the line? The public subset isn't some arbitrary interface that could have different implementations. And even then, "equals under interface I1" would have to be considered a very special type of "equality", not the general case.
The JEP itself highlights the problem of == leaking private details, and recommends avoiding its use in favor of equals(). It also highlights the potential security risk because of this, noting that private fields of value classes should not be considered secret because of this (and the new identityHash method).
The JEP also gives examples of classes where == would return false for instances that would behave exactly the same from an external perspective. They give examples mostly revolving around strings and other reference objects as fields of value objects; and some weirdness around float and double NaN. There's also the classical case of caching, where an object may store the inputs to a complex calculation, but can also cache the result of said calculation - and asking for the value can either perform the calculation, or return the cached result (though Java value classes don't fit this too well, given their limitations of being immutable).
This also has huge implications in a language that emphasises dynamic loading like Java. And it also flies in the face of all of the pretenses that ABI compatibility is sacrosanct and no feature that breaka it can be considered, that the design team often touts.