The codebase appears to have migrated quite a bit since this original patch was tried. Commenting out those lines of code no longer works, however the issue is still valid and has been fixed in http://jira.icefaces.org/browse/ICE-4186.

The upshot of the fix is to enable the redirect-on-pause setting in the src/main/webapp/WEB-INF/config/webflow-config.xml file as follows:

<webflow:flow-executor id="flowExecutor">
<webflow:flow-execution-attributes>
<!-- #4186 comment out for reload support, include for POST-UPDATE type behaviour -->
<!-<webflow:always-redirect-on-pause value="false" />->
</webflow:flow-execution-attributes>
<webflow:flow-execution-listeners>
<webflow:listener ref="jpaFlowExecutionListener" />
<webflow:listener ref="securityFlowExecutionListener" />
</webflow:flow-execution-listeners>
</webflow:flow-executor>

You can comment it out, since the default is "true". Note that this enables the POST->process->REDIRECT pattern as outlined in the 4186 case and disables the faster and more streamlined POST->process-> send updates model in ICEFaces AJAX processing but the two modes are not compatible.

This particular issue is now resolved. If there are further issues related to reload, please refer to 4186 above.

Perhaps you can explain the following then:
I upgraded to 1.8.0DR2 and I got another completely separate issue with stack trace shown below.

I was able to circumvent this error by setting following attribute to false instead of true as in test case
<context-param>
<param-name>com.icesoft.faces.doJSFStateManagement</param-name>
<!-- when following is true: java.lang.IllegalStateException: Duplicate component ID '_id1' found in view. -->
<param-value>false</param-value>
</context-param>

When doing so then everything works again. i.e: going to page 2 and refreshing the state is not lost and it is in fact correctly maintained.

1) Please explain then your above assertion. 2) determine what can be done to have test case work with this parameter set to true
-------------------------------------------------------....

java.lang.IllegalStateException: Duplicate component ID '_id1' found in view.
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:201)
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:204)
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:204)
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:204)
at com.sun.faces.application.StateManagerImpl.saveSerializedView(StateManagerImpl.java:97)
at org.springframework.faces.webflow.FlowViewStateManager.saveSerializedView(FlowViewStateManager.java:129)
at com.icesoft.faces.application.D2DViewHandler.invokeStateSaving(D2DViewHandler.java:731)
at com.icesoft.faces.facelets.D2DFaceletViewHandler.renderResponse(D2DFaceletViewHandler.java:284)
at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:156)
at org.springframework.faces.ui.IncludeViewHandler.delegateViewHandler(IncludeViewHandler.java:268)
at org.springframework.faces.ui.IncludeViewHandler.renderView(IncludeViewHandler.java:258)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)

After debugging and analyzing the provided source code I am convinced that ICEfaces behaves as expected. On a page reload only the fragment included with webflow:include tag is reset. The fragment is rendered by org.springframework.faces.ui.IncludeViewHandler and the decision of what page needs to be included belongs to org.springframework.webflow.engine.ViewState.
This stack trace shows how Spring Webflow and ICEfaces interact:
at org.springframework.faces.ui.IncludeViewHandler.renderView(IncludeViewHandler.java:57)
at org.springframework.faces.webflow.JsfView.render(JsfView.java:97)
at org.springframework.webflow.engine.ViewState.render(ViewState.java:245)
at org.springframework.webflow.engine.ViewState.resume(ViewState.java:204)
at org.springframework.webflow.engine.Flow.resume(Flow.java:545)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:262)
at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:163)
at org.springframework.faces.ui.WebFlowBoundaryComponent$1.doInComponentContext(WebFlowBoundaryComponent.java:66)
at org.springframework.faces.ui.WebflowTemplate.doExecute(WebflowTemplate.java:104)
at org.springframework.faces.ui.WebflowTemplate.execute(WebflowTemplate.java:51)
at org.springframework.faces.ui.WebFlowBoundaryComponent.encodeChildren(WebFlowBoundaryComponent.java:58)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:354)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:96)

The test case does work with 1.7.2 release because ICEfaces used to execute only the render phase on a page reload. Since ICE-3944 was fixed the full lifecycle is executed, including "Restore View" phase.
In conclusion I believe it is org.springframework.webflow.engine.ViewState's responsibility to remember the page it needs to render and not ICEface's/JSF.

Tyler, do you still have the test case somewhere? I cannot find it on the FTP server. Without it I can just guess what could go wrong...

Any progress on this?