Example for scenario #1 above:

<h:body>
    <f:view>
        <ace:ajax render="output">
        <h:form>
            <h3>This Ajax is Default Triggered</h3>
            <h:inputText id="input" value="#{indexBean.message}"
                valueChangeListener="#{indexBean.valueChange}"/>
            #{' '}
            <h:commandButton value="Display" action="#{indexBean.displayText}">
            </h:commandButton>
            #{' '}
            <h:commandLink value="Display" action="#{indexBean.displayText}">
            </h:commandLink>
            #{' '}
            <h:outputText id="output" value="#{indexBean.message}"></h:outputText>
        </h:form>
        </f:ajax>
    </f:view>
</h:body>

Example for scenario #2 above:

<h:body>
    <f:view>
        <h:form>
            <h:inputText id="input" value="#{indexBean.message}"
                valueChangeListener="#{indexBean.valueChange}"/>
            #{' '}
            <h:commandButton value="Display" action="#{indexBean.displayText}">
            </h:commandButton>
           <ace:ajax render="output">
               #{' '}
               <h:commandLink value="Display" action="#{indexBean.displayText}">
               </h:commandLink>
               #{' '}
               <h:outputText id="output" value="#{indexBean.message}"></h:outputText>
            </ace:ajax>
        </h:form>
        </f:ajax>
    </f:view>
</h:body>

Committed improvement to the 4.0 trunk at revision 41494.

Since our ace:ajax tag is modelled after the f:ajax tag of Mojarra, to add this improvement an approach similar to that of Mojarra was implemented. The main idea is to create an application-scoped stack that stores client behavior settings. Then, as the facelet tags are being processed, when an ace:ajax tag is reached, after we determine that the ace:ajax tag is wrapping other components (in our AjaxBehaviorHandler class), we add the facelet context, tag settings and event name to this stack. Then all the tags of components that implement IceClientBehaviorHolder will look for this stack and add the behaviours to the newly-created component. After all children of the ace:ajax tag have been processed, the behaviour settings are removed (popped) from the stack.

Thus, the ace:ajax tag follows the same rules or precedence described in the section 10.4.1.1 of the JSF 2.0 specification.

Unfortunately, at the moment it doesn't seem feasible to also support/affect standard (h: ) components nested inside our ace:ajax tag, since Mojarra and Myfaces use different approaches to support f:ajax in wrapping mode. Each of them uses their own classes that aren't part of the standard API. Many of these methods are private and we can't access them. Also, the different component implementations expect different things to be available when looking for ajax behaviours defined by a wrapping tag. There might also be some conflicts using ids to store application-wide objects. Each implementation has its own approach since the JSF specification doesn't mention any details regarding how this mechanism should be implemented. Also, when traversing the tag tree, it's not possible to directly access tag children and the components they create at the times where it would be optimal do be able to do so.

However, both ace:ajax and f:ajax tags can coexist and each will only affect the components they support. It's possible to wrap a set of ace: and h: components inside an ace:ajax and f:ajax tag. The order is not relevant.

New failures are seen with certain ace:dataTable test applications. Tomcat 7, all browsers. Icefaces 4 trunk r41494.
The new failures are seen in the following test applications:
Row State EL
Input Component Processing
Input Component Processing/ with FAjax
StateMap Size
StateMap Sync
Not an issue with ee-maintenance branch.
Browser error appears:
For input string: "7895466090007243068:-5492966339740380774"
class.java.lang.NumberFormatException
Text input changes to a large number after submission.
Example: "test1" was entered into the UPC header filter. Input was submitted. The return value of the input is correct but the textEntry value changes to number. See screen shots before.PNG, after.PNG
Test application located at:
C:\svn\repo\qa\trunk\Regression-Icefaces4\Sparkle\Nightly\dataTable

I haven't been able to see/reproduce those last issues. I checked out the test application from...

http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataTable

...and I navigated to the pages 'Input Component Processing' and 'Input Component Processing w/ f:ajax'. Then, I entered 'test1' and 'test2' in the filter fields of the first two columns, respectively, and then I clicked the submit button, and both filter strings stayed the same; they didn't change to a number. I didn't see errors in the server console nor in the browser console either.

Can you please provide steps to reproduce the issues in other test pages?

The input Component Processing test produces this error when entering test into the first 2 test applications header fields. In the normal header test the input text is changed, in the 2nd app (multi row header) the input field displays correctly but the submit button below the table displays the long number as a value instead of "Submit". See screen shot Multi.PNG. These results were produced on 3 different machines using IF4 code revisions 41494, 41495 and 41497.
For the other applications just general interaction would spawn the error, inputting text or clicking on table rows.
Server errors are also seen
Jun 19, 2014 4:31:56 PM com.sun.faces.lifecycle.ApplyRequestValuesPhase execute
WARNING: For input string: "-4144328025155680052:4219605870235345986"
java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:495)
at java.lang.Integer.parseInt(Integer.java:527)
at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState
at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53)
at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43)
at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831)
at org.icefaces.ace.component.datatable.DataTable.processDecodes(DataTable.java:456)
at javax.faces.component.UIForm.processDecodes(UIForm.java:225)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220)....

Jun 19, 2014 4:31:56 PM com.sun.faces.context.AjaxExceptionHandlerImpl handlePartialResponseError
SEVERE: java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:495)
at java.lang.Integer.parseInt(Integer.java:527)
at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState.java:114)
at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53)
at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43)
at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831)...........

The last issues reported above are not caused by this fix. They are caused by ICE-9953.

You can try reverting the core and push folders to the revision before the ICE-9953 commit (41493) and you can see that these issues aren't present, whether the fix for ICE-10080 is in effect or not. Likewise, using jars (core and push) with the ICE-9953 fix, these issues will happen, whether the ace jar has the ICE-10080 fix or not.

Please re-open ICE-9953 or create another JIRA for these new issues.