UML25 — Location p 153 complete_and_disjoint: Abstract Implication

I'm not sure this is correct. i see the logic of saying this, but I can imagine circumstances where the generalization would be complete and disjoint, but the generalization class would be useful to instantiate as a temporary until I determine which one of the subclasses it is.

Forcing it to be abstract is a coding style limitation, which should not be required

Actually this constraint was not there in UML 2.4.1 so should not have been introduced, independently of
coding style discussions.
In the related examples in clause 9, the superclass is in fact abstract; remove the implication that this is a
consequence of the generalization set.