With the current trunk (as of 11/23/09) it seems to work better.
However, navigation works only if an action has been executed on the current page.
If not, the following is logged:

23.11.2009 11:04:00 org.icefaces.context.DOMPartialViewContext applyBrowserChanges
WARNUNG: DOM is null during applyBrowserChanges
23.11.2009 11:04:00 org.icefaces.context.DOMPartialViewContext processPartial
WARNUNG: Old DOM is null during domDiff calculation

and navigation fails (We stay on the same page, nothing is logged). If after that, an action is exeuted, navigation works again.

Unfortunately, the fact that the navigation works after the action is not entirely benign. What is happening, is that the entire form is being replaced, so the ICEfaces form submit interception is being turned off, and the page is reverting to a non-Ajax method (standard form POST with full page refresh).

After repeated navigation back and forth, the following Exceptions are sometimes seen:

java.lang.RuntimeException: Unknown window scope ID: 1259183042529
at org.icefaces.application.WindowScopeManager.determineWindowID(WindowScopeManager.java:64)
at org.icefaces.push.BridgeSetup.renderView(BridgeSetup.java:67)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:127)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:637)

java.lang.NullPointerException
com.sun.faces.application.view.StateManagementStrategyImpl$4.invokeContextCallback(StateManagementStrategyImpl.java:289)
javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:1250)
javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:672)
com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:284)
com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:177)
com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:131)
com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:429)
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:143)
javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:288)
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:199)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:310)

The "basic" demo now has both outputLinks and commandButtons for switching between ICEfaces and non-ICEfaces pages. Navigation is initially possible, but eventually the following Exception is thrown:

javax.faces.FacesException: java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to com.sun.faces.application.view.StateHolderSaver
at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:1253)
at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:672)
at com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:284)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:177)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:131)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:429)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:143)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:288)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:199)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to com.sun.faces.application.view.StateHolderSaver
at com.sun.faces.application.view.StateManagementStrategyImpl$4.invokeContextCallback(StateManagementStrategyImpl.java:288)
at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:1250)
... 24 more

Bug in JSF 2.0 is suspected:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1427

This bug partly arises from the use of addComponentResource in BridgeSetup.java. It may be possible to use the DOMRenderKit to wrap certain Renderers with a ResourceDependency-bearing class.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1427

User edburns changed the following:

What |Old value |New value
================================================================================
Status|NEW |STARTED
--------------------------------------------------------------------------------
Priority|P3 |P2
--------------------------------------------------------------------------------
Target milestone|2.0.next |2.0.3
--------------------------------------------------------------------------------

Update from Roger:

We have a slightly alternative solution for this fix as making the component transient works fine
in certain (but not all) situations. I'm working on that and will test it and keep you posted.

The following hack in

core/src/main/java/org/icefaces/facelets/tag/icefaces/core/ConfigHandler.java

attributes.put( EnvUtils.ARIA_ENABLED,
new Boolean(ariaEnabled.getValue()) );
}
+ //TODO: remove when JSF 2.0 Partial State Saving fixed
+ //touched in the head
+ facesContext.getViewRoot().addComponentResource( facesContext,
+ new UIOutput(), "head" );
}
}

has been added. This "works" because it causes the HEAD resource component to use the same state-saving strategy on the ICEfaces page as on the non-ICEfaces page with an f:ajax component. Without this, ICEfaces will attempt to dynamically add resources to the HEAD just prior to render (well after Facelet page assembly), causing the HEAD resource component to use a DYNAMIC_COMPONENT strategy in com/sun/faces/application/view/StateManagementStrategyImpl.java. This is incompatible with the component with the same ID used by the navigated-to page since the f:ajax tag forces the non-dynamic strategy.

I've added an additional line of code to touch the body as well:

facesContext.getViewRoot().addComponentResource( facesContext, new UIOutput(), "head" );

This seems to ensure that the same state-saving strategy is employed and I now no longer see any of the noted exceptions. Resolving as fixed.

Noting that this fix is currently dependent on 2.0.2 and should be re-examined when Mojarra 2.0.3 is officially available.