When two ids match, then the two instances match as well.

Sure, I agree. But my id:s don't match. I have two different instances. One A and one B, with two different id:s.

Likewise, you can consider version as part of the general identity of the entity, that's why it has to be defined on the root entity.

Well I don't think so. A has no version attribute. How can a version attribute that doesn't exist be part of A's identity? Besides, sticking to reality, then we both know that @Id and @Version are two completely different things.

Here's the real example that I use in my code (a bit simplified of course):

@Entity
public class Counter
{
    @Id
    @GeneratedValue
    private long id;
}

@Entity
@Table(name = "VERSIONED_COUNTER")
public class VersionedCounter extends Counter
{
    @Version
    private int modCount;
}

Making the superclass a @MappedSuperclass is out of the question for me. Because Counter is and will always be an entity on its own. The real difference between the two counters here in this example is that one uses optimistic locking while the other one does not.

EclipseLink has no problems with this code, nor do the JPA specification. And for my part, I haven't really understood your point of view. What exactly would the harm be?