But there is a difference; imo a crucial difference. In your example, the "different behavior" is inherent in the class itself. In fact, in OO design this is a good principle called polymorphic behavior. In the case of optimistic locking, the difference in behavior is not inherent to the class; optimistic locking is just an example of meta programming essentially: you are annotating your classes (or mapping in XML) with the expectation that something external to your classes will operate on that.

I am just not convinced that your model is the right illustration of why we need to change this. Maybe there is a convincing illustration/model out there.

If you really feel you need mixed optimistic locking within your hierarchy, have you considered using a pattern like so for your model?:

interface Counter {
    // common behavior
}

@Entity
class UnversionedCounter implements Counter {
    @Id
    @GeneratedValue
    private long id;
    ...
}

@Entity
class VersionedCounter implements Counter {
    @Id
    @GeneratedValue
    private long id;

    @Version
    private int modCount;
    ...
}

Or even:

@MappedSuperclass
interface Counter {
    @Id
    @GeneratedValue
    private long id;

    // common behavior

    ...
}

@Entity
class UnversionedCounter implements Counter {
    ...
}

@Entity
class VersionedCounter implements Counter {
    @Version
    private int modCount;
    ...
}

These can then be mapped as associations (if needed) using @Any