Hi,
Looks like a good start! I became a bit curious regarding the case when the state-machine already exist (with the initial elements already created) before you establish the generalization. But I guess that is still work in progress to ensure that the existing elements are removed in the subclass (as I commented on the bug).
Regarding the issue with nested state-machine diagram of an inherited composite state, what you propose (if I understood the details correctly), is perfectly in line with what the legacy tooling does as well.
If you double-click on an inherited composite state the following dialog pops up:
As you can see from the options presented to the user, it is exactly as you propose. Either the user navigates to the inherited state machine diagram, i.e. it opens the diagram in the context of the superclass, or the user selects to redefine the state and create a local state machine diagram and open it in the context of the subclass.
When the redefinition have been made, the double-click action the naturally always takes you to the local (redefined) state-machine diagram. The dialog only pops up in the case the composite state is not yet redefined.
I suggest that we, as you propose, align with the legacy tooling and introduce a similar dialog with those two options.
/Peter Cigéhn
_______________________________________________