I am working on creating a proposal for a different KSS semantics, that would support our use cases in a better way then the current format. Work is under progress, I will report as soon as my proposal is ready for discussion.

Main motivation for this are the following:

1. I was the one that wanted to push the support for "more actions in one event". However while I still believe that there are use cases for this, I suggest to forget about this now. A particular problem is that all parameters will go into one line in our current  case, thus 90% of all selectors will be a one-liner and a large part of expressivity of KSS gets lost. I feel we are better off when we drop expressing the "more actions in one event" and get back the parameters to different rows We might find another way for extending the acions later on.
2. The second problem is that in the framework diagram we have "event nodes" with more incoming arrows ("the events") and more outgoing ones "the actions". Till now we were mainly dealing with events that simply dispatch to calling a remote action, but for some use cases more is needed. When we want to enable the creation of more complex events, we need to support a kind of object oriented structure, where an "event instance" is created when the event is bound, and it operates like a state machine, being able to execute more different type of actions ("the methods"). We want to be able to map this schema in some way, event though we might not implement this right now. What we do want to implement, though, is exception handling, and the other thing we want immediately is better interfacing possibility to existing Bling software (although Godefroid is currently working on a totally transparent method that might not even need this.) In other words not only we need a bit more natural reading format but we also want to be able to extend it later on.
   
3. A more sensible way to define action parameters will disqualify 90% of the need for creating new plugin actions. As it seemed till now that they were mostly necessary because we could not come up with a sensible way of parameters handling in actions.
   
4.  Last but not least there were a bunch of problems with the original kss syntax, that in this case don't need to be solved.

I apilogize for being too abstract here; indeed it is difficult to discuss this without concrete examples. All this and more is coming up soon.