Event Listeners without a defined Event (User or Timer) are concrete elements and can be added to CMMN models.
However, the execution semantics are not clear.
Is the listener immediately triggered since there is nothing to wait for? Or does it wait indefinitely since there is nothing to wait for?
[the former would be preferable]

There are modeling styles that would use empty Event Listeners and it should be made clear if this is valid for execution.

In spec text and meta-model the Diagram Interchange attributes fillColor, strokeColor and fontColor are spelled with a lowercase first letter. However, in the XML Schemal they are spelled with an uppercase first letter: FillColor, StrokeColor and FontColor.

Proposal:
Adjust spelling in text and MM, because XSD is already implemented and in use.

All initial transitions (create transitions) contain "create" trigger/event. It's illegal according to UML specification (State Machines).
We could use "/create" instead to specify what kind of behavior is executing while transiting from initial node to the first state e.g. Active.

I was wondering why the stage autocomplete doesn't take into account the event listeners. At some point in time, it might be possible that a stage has no active children, but an event is still waiting for something. So in this case, I would expect that the stage doesn't autocomplete until the event has happened.

Is there a reason why this is implemented otherwise?

Figure 7.4 'CMMN Shape' shows an attribute isExpanded instead of isCollapsed, which is described in spec text, tables and XML schema.

Proposal:
In Figure 7.4 on page 85 (PDF 101) replace attribute isExpanded with isCollapsed.

Problem Desciption

The condition expression of ManualActivationRules, RequiredRules and RepetitionRules is optional as shown in Figure 5.13 (PlanItemControl class diagram) on page 50 (PDF 66).
Therefore, CMMN has to define default behaviors for two cases:

1. A ManualActivationRule, RequiredRule and RepetitionRule is not present at all
2. A ManualActivationRule, RequiredRule or RepetitionRule is present, but has no condition expression defined.

The following sentences seem to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 50 (PDF 66):

"A ManualActivationRule comprises of an Expression that MUST evaluate to boolean. If no ManualActivationRule is specified, then the default is considered “true.”"

However, instead of defining the behavior for a missing condition expression (case 2), it talks about the marker itself and thereby accidentally makes all tasks and stages manual by default if they don't have the manual activation marker (case 1).
This is completely contradicting the meaning of the manual activation marker: It would mean that a task can only be activated automatically, if it has a ManualActivationRule with a condition set to "false". By having a ManualActivationRule that task also gets the manual activation marker although it is activated automatically. On the other hand a task that has no ManualActivationRule would not get the manual activation marker although it is activated manually.

Similar sentences are correct for case 1, but fail to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 51 (PDF 67):

"A RequiredRule comprises of an Expression that MUST evaluate to boolean. If no RequiredRule is specified, the default is “false.”"

"A RepetitionRule comprises of an Expression that MUST evaluate to boolean. If no RepetitionRule object is specified, the default is “false.”"

Furthermore, there is a cardinality mismatch between Tables 5.50, 5.51 & 5.52 and MM/XSD for conditions of ManualActivationRules, RequiredRules and RepetitionRules

Recomendation

This issue has been confirmed by people that worked in the CMMN specification. In particular: Mike Marin (IBM), Denis Gagné (Trisotech), Henk de Man (VDMbee), Ralf Mueller (Oracle) and Falko Menge (Camunda). They expect to see this issue fixed in the next CMMN version. In the meantime, they encourage all implementers and users of CMMN to read "false" instead of "true" in the description of attribute manualActivationRule in CMMN 1.1 Table 5.49 (PlanItemControl attributes and model associations), because the current specification text can lead to misinterpretations. Correct behavior is described in the following image:

Proposal for Specification Text

In Table 5.49 (PlanItemControl attributes and model associations) on page 50 (PDF 66):

replace the following sentence:

"If no ManualActivationRule is specified, then the default is considered “true.”"

with:

"If no ManualActivationRule is specified, then the default is considered “false.”"

In Table 5.50 (ManualActivationRule attributes) on page 52 (PDF 68):

Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:

"If no Expression is specified, then the default is considered “true.”"

In Table 5.51 (RequiredRule attributes) on page 52 (PDF 68):

Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:

"If no Expression is specified, then the default is considered “true.”"

In Table 5.52 (RepetitionRule attributes) on page 53 (PDF 69):

Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:

"If no Expression is specified, then the default is considered “true.”"

Meta Model and XML schema use condition with lowercase c whereas Table 5.51 uses an uppercase C.

Proposal:
In Table 5.51 - RequiredRule attributes on page 52 (PDF 68) replace "Condition" with "condition".

It may be useful to be able to define the Performer for task of type Process and Case

When visually modeling it is often desired to have a planItem react to multiple standard events (e.g. when a certain caseFileItem is created or update or addchild or removechild etc. do this).
Presently it is required to visually depict multiple copies of the caseFileItem with a separate onPart for each of the Standard events we want to react to because onPart can only have one standard event.
It is proposed to allow onPart to have multiple standard events defined all of them in a disjontion (e.g. created OR addchild OR removechild or etc.)