The problem is that if you specialise a terminology constraint, just like for any other constraint, you can only narrow / specialise it. That means only:
- reducing it, e.g. going from {at1, at2, at3} to {at1, at2} in the child
- adding proper child codes that are specialisations of existing codes, which has an effect like making the value set bigger, but only with more specialised codes {at1, at1.1, at1.2, at1.3, at2, at3}
The need the modellers have is to sometimes be able to treat the initial code set as a suggestion, or preference, without it being a true constraint. In case you feel discomfort at this, join the club 
However, there is an unavoidable reality that this does happen pretty frequently.
So we need a way of dealing with it, which is the proposed modification of the C_TERMINOLOGY_CODE constraint type, to mark a value set as being required | extensible | preferred | example (the FHIR settings). If you analyse it carefully, it’s difficult to show how these would even work that well in reality - e.g. what happens if you set something to ‘required’, and later on, you want to break the constraint? And the difference between extensible and preferred sounds ok informally, but in terms of real modelling and real processing… not so much.
However, having read a lot of these requirements over the years, I don’t have a better proposal (well, I would probably collapse extensible and preferred, but that’s a detail), so I guess we will do this change.