please ignore this post. forget about it :-)
The motivation to look into typed signals was to force some kind of activity instance. Now I remember why I didn't do it before: there is no other way then to force a lot of overhead. First, for each external trigger, an extra record would need to be kept. Second, in the runtime transition, the input signal would need to be matched and converted into a signal that is extracted from the execution.
There are 2 ways to look at state machine execution:
1) you just feed in the external signals. it's up to the caller (and his architecture) to know what triggers that can be fed into the state machine.
2) you ask the state machine the trigger before you signal it.
I think that both options should be possible. In the original post on this topic, I wanted to exclude one, which is not good.
I only now realize that you can do 2 also with the current API's: an activity instance id can be generated by the activity and made available somehow to the client (SignalDefinition?). Then the client can pass the activity instance id with the parameters. the activity can then check it if it wants to.
I'll see if i can work out a simple wait state in both ways to show what i mean.