I see us having a separate layer, not doing modifications directly on the core model. But we need to start actually fleshing this out to see how it works. I want to start with deployments; perhaps you can identify one or two more types of modifications that are fairly representative of different types of problems we need to handle?
David might want to comment further, but I think we should look at the AbstractModelElement.appendDifferences() method as an initial idea on how to deal with updates, something we can supplement or even move away from completely. It's based on the idea that we have another instance of the model and we then calculate differences and based on those create update actions. It's not clear where that other instance of the model comes from. One of the nice aspects of the appendDifferences idea is only update classes have access to the package-protected modifier methods on the model objects. But then how is the other instance of the model created?
Re: validation -- forgive me for a bit of a tangent: even with the more limited task we've done up to now of creating model objects by parsing, I think we're missing an explicit validation phase. For one thing, it's needed to give model elements a chance to resolve any references to other model elements. I've done a bit of that with RefResolver being passed into model element constructors, but there are cases where it's not valid to try and resolve the reference in the constructor (since the referent may not have been parsed yet). Now we're not resolving until the element is activated, which is too late.
When we talked a week or so ago about a proper reference notion, I was thinking mostly in terms of the rename use case. So if socket-binding "foo" gets renamed "bar", any referring elements are aware of that and change their config to read "bar". But I think a richer reference notion can apply to other problems as well. For example, ServerGroupElement has a fully fleshed out "reference object" linking it to a ProfileElement. So if the ProfileElement is changed (either directly or via a change to a child subsystem) the ServerGroupElement is aware of that. We then use that information to figure out what to push out to the ServerManagers (and on to the Servers).