We could create some mechanism, that developers could opt into, on a bean by bean basis, or even property by property basis, of carrying forward state from the old bean into the new bean. We could provide an API, which would protect developers from the implementation details, that would provide a place for the bean to save its state to on dispose(), so that the new bean could retrieve that state, when it's constructed. Special care would be taken so that it would work with concurrent DOM views, so that one view would not get confused with another. Mircea recommended some combination of TheadLocal storage and the FacesContext.

Another idea, from Ted, is to just use Java 1.5 Annotations, so that the framework would handle the state propagation, and the bean's wouldn't have to code to any API, beyond using the appropriate Annotations, of course. We may have to use a combination of an API and Annotations, for Java 1.4 compatibility. But it's probably best if we just do the Java 1.5 approach first, and gauge demand for the API approach, later.

Then I realised, that there's not much difference between solving bean state propagation between refreshes, and between any GET or POST, for redirects or any regular Ajax interaction. Basically, we theoretically could remove long-lived request scope for beans, and use standard request scope, yet maintain the bean state for long lived request, or any duration. We could provide annotations for each transition, where a request bean would typically be disposed, where we could propagate the state, like redirect navigation rules, Ajax POSTs, refreshes, etc. That might be more granular, and precise than coming up with arbitrary names like "Page" or "Window" scoping.