The documentation for id says "uniquely identify" but not the scope - within a single model, universally?
And for humanID (sic) it's also vague: "the uniqueness of this identifier within a model or relative to some other context."

The intended usage is unclear - calling it "human" does not seem helpful since it's presumably not for human consumption e.g. for display on a diagram?
And "human" is also wrong if the model was generated by a tool, i.e. the "modeler" is not a human.

Without further rules, or a compliance point, interoperability becomes unnecessarily hard.

id is not an acronym but short for identifier. So for consistency with the "id" property, and camelcase rules, they should be humanId and aliasId

ElementType seems to have no way to represent the properties of the type, and TypedElement seems to have no way to represent the values of any properties.
All you can represent is ElementRelationships.
8.1.3 says "entity-type “Thoroughbred Horse” that is used to specific the basic characteristics of thoroughbred horses." but there is nothing I can see that could represent those characteristics, nor their values for the Element Secretariat.

Name is odd if it's meant to represent a specific version. For example OWL uses versionIRI for this.

Though Vocabulary in SCE would correspond to Dictionary in MVF, since SemanticElement in SCE corresponds with MVFEntry in MVF.

As part of our approach to create a MVP SCE, we should refactor the packaging mechanisms so that BPMN, CMMN, and particularly DMN can use the SCE infrastructure

The inclusion of instance elements for modeling and exchange is limited in BPM+ to PMN and PPMN (which is dependent on PMN). It is not currently considered to be a generic enough feature to be included in SCE, since most BPM+ languages do not need it.
Thus, in the interest in creating an MVP SCE, it is suggested here that the instance definition elements be removed in SCE and placed in PMN where it is first needed.
This issue was identified through issue SCE-40, which deals with making SCE backwards compatible to the original BPM+ languages. However, there are other elements besides the SCEIntances package that need to be moved, such as TypedElement.
The proposal for this issue will be layered upon (dependent on) the resolution for SCE-40.

Replace Figure 11 Annotations, which shows the older version of SCEElement.

to be MOF compliance

As part of finalizing an minimum viable product for SCE, remove the vocabulary mechanism. There has been much discussion about the topic and the necessity for the capability has been questioned.
In any case, the current mechanism doesn't work, especially which the proposed change to Semantic Reference.
We may need to include some sort of extendible enumeration capability at some point. This will be handled in conjunction with review of BKPMN, PPMN, PMN, and SDMN enumeration requirements.

The Import section has some inaccuracies and should be refactored to be a very general mechanism as a foundation for the specs that use SCE. Further import constraints will have to be defined for each language.

The current SCE XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.

RelationshipKinds should be well-known set of kinds. These kinds have semantic meaning and have notational impacts. Thus, they should be part of the normative spec through a standard enumeration (or perhaps sub-classes).

if this is to be the target of using substitutionGroup, then

<xsd:element name="modelArtifact" type="sce:tModelArtifact" minOccurs="0" maxOccurs="unbounded">

should be:

<xsd:element ref="sce:ModelArtifact" minOccurs="0" maxOccurs="unbounded"/>

the wrong type of element in XSD for ModelArtifact – should be a ref

all types should start with 't'

all types should start with 't'

I would suggest all acronyms be capitalized. All types start with 't'.

Fix all identified typos in the beta Spec, if they have not been identified in other issues

This will ensure that all downstream languages will use the same notation if they have connectors based on the RelationshipKinds.

Basically all lines between model elements in all the BPM+ models (BPMN, CMMN, DMN, SDMN, BKPMN, Parties, and PPMN) should be (theoretically maybe) derived from one of the SCE Relationship Kinds.
And if we define the basic notation for each of these relationships, then all subsequent models will provide consistent relationship notations.

The changes to the current SCEVocabulary models should be mapped to MVF.

to be MOF compliant

They are optional properties and can be used by multiple languages, including the original BPM+ languages.

This will probably affect the packaging structures more than anything.
If done properly, it may be possible for current BPM+ vendors to overlay those models on top of SCE.
Falko Menge has already done some testing of the BPMN schema utilizing SCE. There are some breakages that may be fixed through SCE adjustments.
We may need to reconsider the PPMN requirements for Instance packages as part of SCE (and move to PPMN directly).