The implementation of AjaxStateManager changes the general behaviour of JSF and breaks the JSF spec. If Richfaces 3.1.x is deployed with an JSF 1.1 webapp a previous state of a view is (wrongly) restored after a redirect. If Richfaces is not deployed with the same application a new fresh view is created in this case.
I provided a small test case that does not use any Richfaces components. Set up a very simple JSF webapp with the Sun RI or Myfaces - it doesn't matter.
Now the test case WITHOUT Richfaces:
1. open testCase.jsf in your browser
2. enter something different into the first input field
3. click "validate"
You should see some error messages.
4. now click "navigate"
Now the validation will be skipped and the simple navigation rule of the faces-config will kick in: redirecting to the same page. You will see "test" in the first input field. Everything worked fine.
Now the ERROR: Install Richfaces 3.1.x into the app and do the same as described above.
After you clicked "navigate" you will see, that the first input field does not read "test" - instead it still shows the input entered before navigating to the page.
It seems that Richfaces always does restore an previous version of the viewstate if a navigation rule that uses a redirect was used. This is wrong. After a navigation with or without a redirect always a new fresh view/viewsate should be created.
By the way: If you use Ajax4jsf 1.1.x or remove the "redirect" tag from the navigation rule the test case works fine as the version without Richfaces.
I traced down the problem to AjaxStateManager line 292 (Richfaces 3.1.5). It seems that if a viewstate was saved for a view than this viewstate will be restored except there is a newer version or no state. Seems to be a fall-back solution. If a redirect was used no newer version was saved, thus an inappropriate old state will be restored although after a navigation a completly new state should be created for the target view (JSF spec).