UMLR — All actions should be able to own control pins

The specification says:

Control Pins (with isControl=true) are ignored in the constraints that Actions place on Pins.

In other words, any action could have control pins. And this makes sense, since when an object token is accepted at a control pin, the object is not considered. It has the same effect as a control token (except that the pin only accepts one token at a time, whereas incoming control flows always accept all offered tokens). The number of incoming control flows is not limited and the same is true for object flows targeting control pins.

Currently this is only possible for some actions (namely InvocationActions), since the "output" and "input" attributes are derived unions. Their subsets are the special pins that each action can define (like the "target" for a SendSignalAction). InvocationActions can have any number of pins, and some of them can be control pins. These are subsequently not considered when matching the Pins to the Parameters of the invoked Behavior. But an Action like SendSignalAction cannot add another InputPin to be used as control pin.

This should be possible. For example it could be necessary to send a number of signals, then wait for the reception of the same number of signals. With control tokens it would not be possible, since all control tokens will be accepted at once. Adding a control Pin to the AcceptEventAction would solve this problem elegantly (of course I could use a work around).

Suggestion
Add a property "control pins" as subset of "output" and "input".
Add a constraint that all Pins in "control pins" must have isControl=true.