Unsafe messages are defined in isUnsafeMessage(). If a message is unsafe it should only be handled in the default run loop mode. This is e.g. to avoid deleting Cocoa objects when a Cocoa message may be busy processing it (which may happen due to the nature of distributed objects and the fact that we process DO message in 'event tracking' mode).
Vim controllers are released when NSConnectionDidDieNotification is received. This notification can arrive in pretty much any run loop mode so we take care not to act on it until the run loop mode is back to default. Otherwise we run the risk of releasing objects which Cocoa is currently using (e.g. view items) and this leads to crashes.
If processCommandQueue: is called when inProcessCommandQueue is set we add the input to a receive queue and return. This is to ensure that processCommandQueue: can only be called "once at a time". Reentrant calls can be caused by calling a synchronous DO message or by entering a modal loop in the frontend.
There are legitimate instances when the queue should flush even though Vim is exiting, e.g. to display a 'confirm quit' dialog with 'go+=c'. This patch has the negative side-effect that the "dropping DO message" warning may occur more frequently. Another fix for this problem has to be devised.
In performKeyEquivalent: do not pass the key equivalent to defaultMainMenu since this breaks the menus on OS X 10.4. Also, this hack is not strictly needed now that window cycling is hardcoded (and a "New Window" menu is always available on the dock menu) so it is just as well that it is removed.