Even though we've made great progress the mutability of MuleMessage and its properties is still a big problem. It can manifest itself in all sorts of inconsistent properties or even the occasional null value seemingly being set during construction (very rare but ask me for stack trace). The usual suspects are always creation of MuleEvent/MuleMessage and the adding/copying of message properties. Since these properties are all lunmped together in a single map and often modified in nonatomic (yet by themselves threadsafe!) ways, inconsistent message properties can happen and are next to impossible to find.
Ross suggested a multi-level hierarchy of properties (application, session, request) to reduce the chance that properties and consumers of the message scribble over each other. Another idea that I had is explicit locking so that clients can introduce transactional blocks for modifications/snapshot creation etc., however this needs more thought too and would not solve aliasing problems since scribbling would simply happen serialized.
The problem is compounded by mutability and nonatomic access/state management, so we need to address both, ideally by doing away with mutability as much as possible.