Improving propagation of structural changes during reconciliation

[merryman]

Describe the Feature
When applying structural changes to components, we currently only have rudimentary handling of how these structural changes are reflected in the derived components.
The reconciliation algorithm needs to be improved in the following areas:

1.) What does removing a morph do to all of the components down the derivation chain (The children, grandchildren etc...) entail? What happens to the parts that used to have customisations within derivations but are now gone?
2.) What does moving a morph within the component definition, (so just changing the parent) entail for all of the derived components? Are the customisations preserved?
3.) What does replacing a morph within the component definition entail? Do we need a particular replace command for that? Is replacement automatically triggered by removing, adding and naming the new morph the same? What does it entail for all of the derived components?
4.) What needs to be kept in mind is also a tradeoff between correctness and usefulness. What I mean by that is, that not any imaginable behavior of the reconciliation is good if it is correct in a formal sense. We may run into scenarios that although they
resolved correctly, are utterly confusing to the user.