Ronald, where do you think MyFaces creates/saves backing beans with request scope? Right, as MyFaces does not know anything about difficulties with portlet requests, it simply uses the request from the external context.
Before patching the bridge, I spoiled my code with workarounds, saving attributes in session scope and cleaning them after the render phase. But by now I think (and found some confirmation for this on the net) that it is really the bridge's task to carry over the request attributes from the action request to the render request.
Besides, this is completely independant from the portlet-dependant code in MyFaces. I also believe that you can create a generic bridge, but it won't work while the MyFaces implementation has code sections that depend on a flag being set when MyFaces is used in a portlet. Because as long as the bridge does not set this flag, MyFaces will do things that depend on running as a servlet. This dependency is easy to fix in MyFaces if MyFaces can make certain assumptions about the behaviour of the bridge. That's why it won't work unless the two projects start talking to each other (you'll find an issue in MYFACES that I have submitted with a comment that shows that at least some MyFaces developers don't even know about the PB project!).