First of all, I should point out that this sort of behavior is generally not approved of in the transactional world, as it becomes a sticky point in a software defined world. An operator could delete the entire instance, and create it again with the new value. To make a software system realize this is a lot of work. So instead, if this remove-recreate maneuver is really necessary, the system being managed could do this internally+automatically when the particular attribute is being changed. Makes the software world a lot simpler. It's a question of designing systems for software or operators. We have assumed operators for a few decades now, but those days are coming to an end. If we want products viable in the software world, we have to build good (transactional) APIs.
Having said that, if you still want to implement this, I'd propose using NACM rules for this. Using NACM you can assign the CRUDX privileges, as in Create, Read, Update, Delete, Execute. If you exclude Update for some or all groups, I think your goal will be met.
This is certainly also possible to achieve using a validation point, but I feel this breaks the transactional model in a deeper way, so I like this less. Since what you are asking for is bad transactional behavior, it is deliberately not possible to express this behavior using only YANG (must statements etc).
