Using keyboard to get a (context) menu

I'm still annoyed using the start menu with the keyboard.

Raising the start menu with Ctrl+Alt+Space, pressing Alt+A opens the "context" menu for "Apps". But it opens somewhere on the desktop, where the mouse is. The change in the source code should be simple, asking the related control, which opens the "context" menu by clicking, for its window rect and use left-bottom coordinate to open the "context" menu. The OS cares for opening in a way, that it won't cross display borders. Since clicking with the mouse on to such an interactive element like "Apps" or "Backup" raises the "context" menu at the coordinates of the mouse cursor, too, this behavior should be considered to be changed at all.

In the windows world it is a good practice to open menus like these at coordinates related to the UI they belong to.

The needed change is minimal and gives a constant user experience.

Okay. I'm working in a VisualStudio World since years. An all Win32 applications have the possibility to map command IDs to accelerators (keyboard short cuts, hot keys, …) in the resources.

If the pa start menu is visible and has the focus, it could receive WM_COMMAND messages for defined accelerators (in the resources).
It only needs a WM_COMMAND handling for the defined accelerators in its WindowProc or a OnCommand handler (MFC, windows messages map).
In the handler for WM_COMMAND, only those accelerators need special handling, where those act like a menu button opening a kind of cascading sub menu. For those the position of the "cascading sub menu" needs to be calculated independent of the mouse pointer.
If the applicaiton (pa start menu) is HDPI aware, than those calculations may need the DPI of the current display to get the right coordinates.
BTW - I have a multi monitor setup and if the mouse is on the secondary and the pa start menu on the primary, the "cascading sub menu" gets visualized on the secondary monitor.
This not really wanted, is it?

Is the usage of Win32 resources, accelerator tables in the resources possible?

Since I do not know, the environment you develop in, I don't know, if the suggestion with the Win32 resources and the accelerator tables inside the resources would be applicable at all.
In our C++ environment, we do not need hidden buttons to simulate getting the keyboard focus, but use the mentioned accelerator definitions from the Win32 resources of the executable.
Thus the command handler or the WindowProc function handles the incoming WM_COMMAND messages triggered by the defined accelerators, like Alt+A, Alt+O, etc.
On startup you could fill an array/list of vier elements with the coordinates of the four "menu buttons", the left-bottom image/text rectangle point.
In the WindowProc function (e.g.) only the command IDs for Alt+B (Backup), Alt+A (Apps), Alt+S (Search), Alt+H (Help) accelerators would be affected and would use the 0 to 3rd element in the array above (filled on startup) for opening the "cascading sub menu".
If the pa start menu is DPI aware, than a change of the DPI (WM_DPICHANGED message) would need an update of the 4-element array of points.

Okay - no matter how you implement pa start menu, please ensure in some way, that the opened menu are "near" to the UI element, associated with this menu. No more menu on another monitor after pressing e.g. Alt+A, only because the mouse there, would be really appreciated.