The notation tables show various permutations of send/receive actions with various parameter options. They are all shown against a single simple textual example. It is unclear what is the purpose of rationale each permutation.
Graphical Examples need to align with corresponding text examples.

GBNF and notation tables only cover a generic "loop action" which is not aligned with the textual syntax that has 3 specific structured actions:

• while loop action
• for loop action
• if/else action

Each one of the above has a specific textual syntax, that the graphical syntax should align with, to enable proper graphical modeling of actions.

A SysMLv1::InterfaceBlock is mapped to a SysMLv2::PortDefinition, but the owned SysMLv2::ConjugatedPortDefinition is not generated.

The graphical notation makes use of enclosing guillemets to mark up presentation of the metaclass as well as possible metaproperties and metamodel extensions of a model element (i.e., their mapping to the SysML abstract syntax or metamodel). However, there are inconsistencies in their application. The following graphical BNF productions are affected:

• -name-compartment productions,
• -edge and -relationship productions,
• productions including user-defined keywords that extend the metamodel.

Currently, metaproperties of a metaclass are treated in different ways. E.g. in a -name-compartment the isAbstract metaproperty is presented as a leading '«abstract»' literal with its own guillemets, while the isReference metaproperty is included in the main metaclass presentation, e.g., '«ref part»'.

A single, consistent rule should be established for all graphical BNF productions that concern presentation of metamodel information.

In the SysML Specification, 9.2.6.2.4 connections, the base connection usage connections is specified as being a ConcernUsage under "Elements". This should, instead, be ConnectionUsage. (Note that this error is only in the document, and connections is declared correctly in the Connections.sysml model file.

The following example appears in 7.8.2 Enumeration Definitions and Usages:

enum def ConditionColor { red; green; yellow; } 
attribute def ConditionLevel {
    attribute color : ConditionColor; 
}
enum def RiskLevel :> ConditionLevel {
    enum low { color = ConditionColor::green; } 
    enum medium { color = ConditionColor::yellow; } 
    enum high { color = ConditionColor::red; }
}

This is example is not valid, because the color features defined in the enumerated values will have name conflicts with the color feature inherited from ConditionLevel. The intent was probably to have the color features in the enumerated values redefine ConditionLevel::color, but that is currently missing from the example.

The Systems Library model AnalysisCases includes a declaration for AnalysisAction as a specialization of Actions::Action. In the abstract syntax, ActionDefinition::analysisSteps and ActionUsage::analysisSteps are derived to be the subactions that are AnalysisActions.

However, no special semantics are specified for AnalysisActions and no special concrete syntax for defining analysisSteps. So they are never used in practice within user models of analysis caes, so they seem pointless.

According to the constraint checkStateUsageExclusiveStateSpecialization (in 8.3.17.6), a substate of a non-parallel owning state definition or usage must specialize StateAction::exclusiveStates (at least according to the description of the constraint; the OCL is wrong, see SYSML2_-183). However, the feature StateAction::substates actually meets the requirements for the application of checkStateUsageExclusiveSpecialization, which means that it has an implied specialization of exclusiveStates. But exclusiveStates already subsets substates (at least according to the library model in States.sysml; the feature exclusiveStates seems to be missing from subclause 9.2.10.2.1 StateAction), so this would mean that all substates are exclusiveStates, which is, of course, incorrect for the semantics of parallel states.

In 8.3.17.6 StateUsage:

1. The constraint checkStateUsageExclusiveStateSpecialization has the description

   A StateUsage that is a substate usage with a non-parallel owning StateDefinition or StateUsage must directly or indirectly specialize the StateUsage States::State::exclusiveStates from the Systems Model Library.

   However, the OCL for the constraint actually checks for the owning state being parallel (rather than non-parallel) and requires specialization of substates rather than exclusiveStates.

2. The constraint checkStateUsageSubstateSpecialization has the description

   A StateUsage that is a substate usage with a owning StateDefinition or StateUsage that is parallel must directly or indirectly specialize the StateUsage States::State::substates from the Systems Model Library.

   However, the OCL for the constraint actually checks for the owning state being non-parallel (rather than parallel).

3. The operation isSubstateUsage used in the above constraints has the description

   Check if this StateUsage is composite and has an owningType that is an StateDefinition or StateUsage with the given value of isParallel, but is not an entryAction or exitAction. If so, then it represents a StateAction that is a substate or exclusiveState (for isParallel = false) of another StateAction.

   However, the OCL for the operation actually does not check if the state usage is composite and also excludes do actions (in addition to entry and exit actions).