The use cases that lead to this:

1. caching
   We want to make some server actions cacheable (GET request instead of POST), and this should be selectable on a per-server-action basis.
   
2. allowing more rule with the same name
   This is only a problem with local actions. We want to execute, for example, two setStyle client actions from the same event.
3. allowing @@ and other characters in the remote action url
   The remote action name is used as the path relative from the current context, or can be an absolute path. This however contain characters that make a name invalid.
   
4. a generic syntax solution of current executeCommand workaround
   If we execute a client action, we want to have an easy syntax to specify an execution node different from the one that reiggered the event. That should be done by generic syntax.
   
5. parameter syntax for lists (keyPress) and dicts (options)

We make no attempt here to complete the specification for all the above features, just discuss the syntax/semantics changes that would enable to specify them.

The new action control parameters

I suggest to introduce special action parameters that are  distinnguishable from normal action parameters. That is: 

#make-invisible:click {
    action-client: setStyle;
    setStyle-name: display;
    setStyle-value: none;
}

will execute the setStyle action on the node clicked. However the next rule:

#make-invisible:click {
    action-client:                 setStyle;
    setStyle-kssSelector:	   css(div.selectables);  
    setStyle-name:                 display;
    setStyle-value:                none;
}

will set parameters that are not parameters to the action, but modify how it's executed. The previous example solves case 4.

As a consequence there are special parameters (starting with kss and in camelcase) that cannot be used as normal parameters.

In addition the selectors can be set up with the selector type, css, htmlid or any other. A string by default gives a css selector.

ALTERNATELY:

#make-invisible:click {
    action-client:                 setStyle css(div.selectables);  
    setStyle-name:                 display;
    setStyle-value:                none;
}

#make-invisible:click {
    action-server:             doIt;
    doIt-kssUrl:               url(/notes/kss_syntax_changes/kss_base_view/AllYourBase/index.html);
    doIt-value:                "will belong to us.";
}

ALTERNATELY:

#make-invisible:click {
    action-server:             doIt url(/notes/kss_syntax_changes/kss_base_view/AllYourBase/index.html);
    doIt-value:                "will belong to us.";
}

#make-invisible:click {
    action-server:             AllYourBase;
    doIt-kssCacheable:         true;
    doIt-value:                "will belong to us.";
}

Parameter producer functions

Use case 5 is a bit different subject. We want to allow list and dictionary types as parameters. They should be specified as if they were parameter providers:

input#text:keydown {
    evt-keydown-preventdefault: true;
    evt-keydown-keycodes:       list(13, 22);
}

For dicts there is no better way then specifying a string, or we would break out from the css syntax: We suggest not to implement a keyword for dict, especially since normal parameters can be used this way. We will however make sure that the passing of both dict and normal types work.

Also we will make parameter producers pluggable, so extensions will be able to make new ones.

More

Also there would be a need for an int() function. This will convert the string to an integer, and the marshalling of integers should be done as :int. This will eliminate the need for making data type conversion at the entry of the server actions.

I am also considering breaking the css syntax for the sake of cascading functions. According to this the currentFormVarFromKssAttr workaround could disappear and it would be legal to use:

... {
    ...
    xxx-key:       currentFormVar(kssAttr(fieldname));
}

More actions with the same name

with a new syntax, using an alias for another action with the same name we can have the real name in parentesis  that allows execute more operations with the same name (in this case, setStyle) (case 2):

#make-invisible:click {
    action-client:                 setStyle;
    setStyle-kssSelector:	   css(div.selectables);  
    setStyle-name:                 display;
    setStyle-value:                none;

    action-client:                    setBoxStyle(setStyle);
    setBoxStyle-kssSelector:          css(div.boxes);  
    setBoxStyle-name:                 display;
    setBoxStyle-value:                none;
}

ALTERNATELY:

#make-invisible:click {
    action-client:                 setStyle css(div.selectables);  
    setStyle-name:                 display;
    setStyle-value:                none;

    action-client:                    setBoxStyle action(setStyle) css(div.boxes);  
    setBoxStyle-name:                 display;
    setBoxStyle-value:                none;
}

REMARK:

optilude says: do it the other way, ie:

setStyle(setBoxStyle);

or in this case the alternate location would not come to life (well then we have to think about this) but putting the pieces together we'd get:

    action-client:                    setStyle(setBoxStyle) css(div.boxes);

the rest woul dnot change so later on setBoxStyle-name etc. would be used to avoud merging of the parms.