Turns out that adding save/restore state operations to AjaxBehavior was required. Not sure what went wrong before as the initial attempts to add state saving didn't appear to work. In this case, we simply did something similar to what the Mojarra AjaxBehavior class was already doing.

We've now run into a bit of a conundrum. I thought I had tested this before but just to verify if it had an impact or not, I removed the following context parameters from the showcase:

<context-param>
<param-name>org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS</param-name>
<param-value>true</param-value>
</context-param>

<context-param>
<param-name>org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE</param-name>
<param-value>true</param-value>
</context-param>

which, while breaking other things, allows the listeners to fire properly. These parameters were initially added to fix ICE-7017 and related to https://issues.apache.org/jira/browse/MYFACES-3271 as well.

So the issue definitely seems to be that, with MyFaces, when restoring the state, it creates new AjaxBehaviours for the ace:ajax listeners. However, unlike Mojarra, MyFaces uses the instance of the behaviours that were created during view restoration

I've tweaked a number of things (like ensuring transient is set, etc) but haven't yet found a way to either:

1) Tell MyFaces to not use the AjaxBehavior created during the restore view phase or
2) Have the listener attributed re-evaluated so that the listener is not null when the event is broadast to it.

I also haven't been able to come up with a non-ICEfaces test case that shows the same problem.

A couple of other things to note:

I checked another example, the Date Time Entry Ajax Submit example as it's characteristics are very similar to to the Panel Listeners and it turns out that the listener is not fired there either. It's just that there is nothing in the UI to make this easily detectable. The setter is actually updating the date.

To boil down what I think the problem is. The AjaxBehavior(s) associated with the component are being handled differently than Mojarra. When you interact with the component

Mojarra:

AjaxBehaviour 'A' is created as part of Facelets construction
Listener is associated
AjaxBehaviour 'B' is created as part of View restoration
Listener is not associated
AjaxBehaviour 'A' is used (which has the associated Listener)

MyFaces:

AjaxBehaviour 'A' is created as part of Facelets construction
Listener is associated
AjaxBehaviour 'B' is created as part of View restoration
Listener is not associated
AjaxBehaviour 'B' is used (which does not have the associated Listener)