Due to the complexity of FiniteStateMachine types, it shouldn't be necessary to duplicate all of the Base FSM type's States and Transitions in the subtype.
It should ruther be possible to use and override these nodes in the subtype.

The States and Transitions of a FSM being nodes without ModellingRules, paragraph 6.2.2 Instances without ModellingRules of Part 3 applies:
"If no ModellingRule exists then the Node is neither considered for instantiation of a type nor for subtyping.
...This Property would not be considered when creating instances of the type. This is also true for subtyping, that is, subtypes of the type definition would not inherit the referenced Node."
This definition makes much sense, e.g. for properties like the NodeVersion and it shouldn't be bend for State Machines.

Currently there are no rules defined for overriding nodes without ModellingRules.

As a consequence, there could be a suitable pair of ModellingRule/NamingRule defining that:
a) Nodes having this ModellingRule are not considered for instantiation, but they are considered for subtyping.
b) Subtypes of ObjectTypes (and VariableTypes) may override these nodes, in concrete terms a State Machine subtype can override a state and it may add SubStateMachines, Causes and Effects.

Since overriding is based on BrowseNames, the NamingRule shall not ignore the BrowseName. (This implies that the the NamingRule Constraint is not suitable.)

Discussed in phone call 2020-09-29.

Solution: Fix wording of reference type that it is allowed to reference the states of the supertype and add an example on how this is working.

Fixed in Draft3

The discussed solution works for adding SubStateMachines, but not for adding Effects and Causes to transitions (as currently defined in the spec).

Added description and example to Draft6 as discussed in WG meeting.

Agreed to changes in telecon.