ACTIVATE MENU (возможно, и POPUP тоже) и INKEY - две вещи, которые гарантированно грузят процессор, причем, насколько я понимаю, в этом плане от версии к версии ничего не менялось.

SET SYSMENU AUTOMATIC (т.е. то, что делает построитель) - панацея от первого. А второе - и в FPD его нечасто приходилось использовать, а в VFP и вообще необходимости почти не вижу, да и не о нем речь сейчас ;-))).

Кстати, имя для пункта меню как SubMenu, то есть попапа, можно и поменять на нормальный идентификатор на латыни. А уж хот-кеи - это известный глюк, не надо их по умолчанию оставлять, надо менять на латыницу. Или убирать.

Кстати, и вид у меню, которое ACTIVATE MENU довольно попсовый, и работает не так, как win-меню.

Кстати, построитель меню и в самом деле довольно многим не нравится, мне в том числе. Всегда программно пишу меню (причем многое при этом строю). Объекты, правда, здесь не использую, делаю процедурно, но многие делают и объектную обвязку меню. Очень хорошо выходит.

К примеру, мы пишем:
oSysMenu.oPopup("Form").oBar("Open").Skip = .F.
А там выполняется команда:
SET SKIP OF BAR Open OF MENU Form TO .F.
PS: прошу прощения за возможные огрехи в синтаксисе ;-)

Попробуй вместо
SET SYSMENU AUTOMATIC
делать
SET SYSMENU ON
.
Но не уверен, что 1) поможет и 2) при этом не возникнут другие глюки.

Ну так это и будет правильное поведение меню ;-)
А так - общие комментарии:
1. Меню должно быть по возможности похоже на меню других Win-приложений.
2. Горячие клавиши должны быть по крайней мере на постоянные действия, со временем пользователи их запомнят.
3. Меню-центрированное приложение можно смело заменить на навигаторо-центрированное ;-). Т.е. в меню оставить только действия для работы с данными, окнами и т.д., а список форм, доступных для запуска в данной сессии, проводить через специальную форму-навигатор, реализованную, например, на базе Tree-View.
4. Ну и тулбары не игнорировать в качестве привычного пользователям элемента мышиного управления ;-)))