During resolutions of SCE-7 and SCE-96, the three elements RootElement, KindSet, and Kind have been accidentally set as concrete but should have been abstract. In general, all SCE elements should be abstract and then specialized by concrete elements defined by the languages that are based on SCE. Some exceptions to this include concrete DI elements and the Model Artifacts (e.g., Group), which can be directly used by other languages without specializations. But that is not the case for the three classes mentioned before.

In addition, the XSD complex types tModelArtifact, tBaseElement, tElementType, tTypedElement, and tAnnotation are not abstract although their corresponding element definitions and metamodel classes are abstract.

The description of the import element was copied from BPMN and contains information that are not appropriate to SCE, which is an infrastructure specification and not specific to any modeling language.
Note that this text was updated by SCE-36, but the update was not comprehensive enough

Theoretically, SCEDI should be able to be re-used by other BPM+ languages (e.g., SDMN) without the other language creating simple marker classes that do not extend the SCE classes. However, SCEDI was developed with abstract classes. If these classes were changed to concrete, the other languages can remove their unnecessary classes from their languages.

The Annotation class, an abstract class, is no longer necessary since Documentation and Category are no longer subclassing it. With only Attachment subclassing Annotation, it provides no value. It also adds additional structural overhead that is not needed. Further, using the name "Annotation" conflicts with downstream language PPMN that want to use it for an unrelated language element.

XSD Chapter Outdated with incorrect text that was copied from the DMN specification.

The spec should have more descriptions of how SDMN can be used by the other languages. This might affect some SDMN structures.

BPMN Messages are similar to Data Objects. In a sense, they are the Data Objects between Pools. And they can have data structures as well.

The current Data Associations (as well as those in BPMN) allow mapping between two data structures. But there are situations where 2 or more structures should be mapped to another structure. This capability should be added to SDMN. This may involve some signification metamodel adjustments.