Currently the VMMessageReceiver inherits TransactedPollingMessageReceiver. Polling message receivers are really only necessary for transports for which picking up a message is "expensive"; since this transport is local to the same JVM, this condition does not hold; unfortunately this also prevents the VM receiver from being used in configurations where many in-VM events must be received rapidly, since the polling is controlled by the connector's scheduler (which is the right thing to do for all other transports, VM is just the exception to the default rule). Note that this was also true in 1.3.
The emergency fix in MULE-1688 works fine but was only a workaround: similar to JMS XA polling, polling workers are regularly triggered by the scheduler but not if they are already polling/busy, in which case the scheduler thread immediately returns.
The "real" solution would be to make VMMessageReceiver work in a similar fashion to the rewritten non-XA JMS receiver. See my comment on MULE-1688 why I haven't done that yet.