Note however, that despite what Hibernate think about adding a second version attribute to the entity hierarchy, the superclass A in this example do not declare a @Version attribute. So hibernate is wrong.

Hibernate is not wrong. Be realistic. The error message is generic; it says "define/override". The distinction between define and override is actually irrelevant because Hibernate says that @Version should only be associated with the root of an entity hierarchy.

EclipseLink has no problems with this code, nor do the JPA specification.

I get sick of this line of thinking. "The spec does not disallow something, ergo the spec requires it". That is simply not the way a spec works. The feature set of things not supported or not covered by a spec is immense. It is simply unrealistic that a spec mention all things it does not support. For example, JPA does not support storing singletons; but is there any mention of that in the spec? Of course not. The breadth of a spec is what the spec explicitly says is supported. And JPA spec does not say what is supported here. And even worse, you imply that the JPA spec requires we support that. Where do you read that?

And for my part, I haven't really understood your point of view. What exactly would the harm be?

Well I'd actually say the same about your model. IMO it makes no sense. Granted I am not a huge fan of inheritance and so probably am a little biased, but even if I were to use inheritance I think this mixing optimistic locking strategies at various levels of the hierarchy is simply wrong.

As for the "harm", there are simply times Hibernate is asked to deal with subclasses as superclasses, and it is a matter of practicality to have consistent optimisitc locking defined for the whole hierarchy.