It may well be that it is only Seam that triggers the bug - yet there is a strong argument that the bug is in fact in MyFaces server-side state saving:
The problem goes away if you switch to either client-side state saving or use the RI.
Martin, if you are familiar with MyFaces' server-side state saving it should not be to hard to find the culprit.
I gave a reliable way to reproduce the problem - see above.
Matthias, here are some references to the problem (for what it's worth):
In previous versions of the Seam reference MyFaces was explicitly mentioned. Now it's in milder form:
"Some JSF implementations have a broken implementation of server-side state saving that interferes with
Seam's conversation propagation. If you have problems with conversation propagation during form submissions,
try switching to client-side state saving."
The problems manifests in a couple of Jira issues, like this one:
"Right, this is a known bug in MyFaces. Nothing we can do about it, except get off MyFaces and migrate to the RI (which we already did do)."
If you search the forum you'll find many people having problem with MyFaces/Seam. Some of the posts are quite old, but the integration problem still persists:
"Right, this is a known limitation of using Seam with MyFaces, due to how MyFaces does server-side state saving (I'm not going to call it an actual bug in MyFaces, but it is suboptimal)."
"Don't use server side state saving, Seam, and MyFaces - it doesn't work. You should use the RI 1.2 if you can - it's much better. You can use JSF 1.2 with facelets in a 2.4 servlet container."
"Do not use server-side state saving with MyFaces, it's buggy. This has been reported before (search the forum) and your problems with page parameters will go away if you switch to client-side state saving or the JSF reference implementation."
"There were known problems with server side state saving in myfaces. I think you'll need to move to the JSF RI to make it work correctly with seam"