Well, my scenario is not actual team work, it is just my personal experiments with the capabilities of the existing compare and merge facilities in the tool.
The independently added classes mentioned are not intended to have any direct relation to eachother, they are added in two different parallel feature branches as part of the needed extensions for each feature.
Naming is not a problem/issue – any added classes in this scenario will clash beacuse of the implicit class numbering.
Another possibility (apart from removing class numbering completely) is either to relax its semantics (checking) or to offer recalculation of the numbering after certain model changes, such as merge.
I guess code generators could always tie to either name resolution by scope or context or tie to the guid, instead of a volatile numbering principle.
I also noticed that it is difficult to explore some common refactoring changes of the model, since the tool does not seem to support moving of model elements. This is problematic from a change perspective, since the model change of “Move” then needs to be represented with two changes (“delete” + “create”) instead of one (“move”). This means that there will in these scenarios always be two merge decisons, that are difficult to relate two each other, instead of only one merge decision.
Many pairs of merge decisions like this, that the user must be able to keep track of manually, without any model-based support, of course increases the risk for mistakes, making merge unnecessarily complex and fragile to human mistakes.