It is failing in Windows because the LDML keyboard processor has not been fully implemented ldml_processor::get_key_list() it just returns an empty list.

In Windows the Keyman engine needs to register the interest in the preserved keys otherwise it will not be seen in the hook for the Keyman keyboard processor.

Implementation detail:
Of interest with this example also is that the ALT key is in a keyboard rule via the the LDML rule other for modifiers. The get_key_list() will obviously have to do the logical expansion of the rule.

For more information
The Call stack will be
Keyman32Interface::GetKeyboardPreservedKeys
MapKeyboard

@srl295 Could you implement ldml_processor::get_key_list() ?
Some of the necessary processing may already be being done in the ldml_processor when passing the keyboard rules.

I see three of these that don't have any 'interesting' implementation. i'll check over the docs.

    km_core_context_item * get_intermediate_context() override;
    km_core_keyboard_key  * get_key_list() const override;
    km_core_keyboard_imx  * get_imx_list() const override;

get_intermediate_context and get_imx_list are only really relevant for IMX, which LDML keyboards do not support.

Trying to repro the failing case.
Windows 11.
Keyman 18.0.116-alpha (will update and try again).
Notepad.

• q emitted D briefly and then went to the 🅐.
• alt-q and alt-w gave no output, but attempted to open the menu hotkeys.

• alt-q and alt-w gave no output, but attempted to open the menu hotkeys.

This is reproducing the error. As the alt key has not been added a preserved key, see description above. Therefore the ALT key is going through to the application where is is treated and the menu key.

• q emitted D briefly and then went to the 🅐.

Testing this again I can only reproduce it by having caps lock on - in which case D is correct. I am wondering if this was the case when Dina was testing?