You assessment is spot on, but effectively you're patch trims down the multi-threaded event delivery into a single synchronised event handling, that is: for the most/critical part (the actual invocation of the portlet).
However, synchronising only this part still won't make it a 100% bullet proof solution as even in the pre/post processing of the event handling it is possible to encounter threads overwriting part of others state, especially the request attributes.
The real cause of this is that the Pluto Portal Driver doesn't properly manage request states per portlet window itself, but simplistically stores all request state (attributes) within the single underlying client HttpServletRequest.
Please note: this is not an issue of the Pluto container implementation itself which is completely (request) stateless, which was one of the most critical goals of the Pluto 2.0 container redesign.
FYI: in Jetspeed Portal 2.x we actively leverage this capability of the Pluto container for real thread-save parallel request processing and in Jetspeed we maintain the request state for each portlet window completely isolated from the underlying HttpServletRequest.
Providing equally thread-save parallel request processing to the Pluto Portal Driver would require very extensive enhancements and redesign.
However that would clearly go way beyond its purpose and scope as being primarily a test bed for the portlet container itself.
The Pluto Portal Driver never was intended nor scoped as a production quality portal solution.
Production quality features like parallel request processing (and many others) however can be found in real portal solutions like Jetspeed Portal.
My conclusion is that the multi-threaded event delivery as implemented in the EventProcessingServiceImpl of the Pluto Portal Driver is fundamentally unreliable and beyond the intended scope and purpose.
I will therefore disable this "feature" and replace it with a plain in-process event delivery solution by copying the logic from the PortletWindowThread.run() method inline in the EventProcessingServiceImpl.