@mwieder: The triggering of mouseDown when using menu shortcuts is a feature, not a bug. Or at least it's supposed to be. The goal there was to provide a single message a menu bar can respond to to update its menus before processing the key event.
Either mousing down in the menu bar or triggering a menu item via a keyboard shortcut may or may not do what you need depending on whether the menu item is enabled.
In the olden days (before this mouseDown event was added in response to menu shortcuts) we had to resort to all manner of odd workarounds to keep our menu items in synch with the environment they represent. With this addition, the hope is that we can now write one update handler for the menu bar, and know that it'll be processed when either the mouse goes down on the menu bar or a menu item is triggered with a shortcut.
In my testing here I've found that when I switch toplevel stacks (by bringing one in front of the other) the menus take longer to render than when the stack layering remains the same. Commenting out the routines that update the File and Edit menus saves significant time, though of course at the cost of not having updated items in those menus.
In the File menu the big time waster is the complete rebuilding of the Recent Files list, which really only needs to be done when a file is closed and then stored somewhere for use during the menu rebuild. When we sort out the IDE contributor process I'll address that.
The Edit menu requires more in-the-moment updating, but I still think there are some ways to optimize that one too.
Community volunteer LiveCode Community Liaison
LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/