Hi @Bill_MI, maybe whitelisting is not the correct term. Maybe “allowed for replay” is more technically accurate. In any case, there are two types of key bindings: global and application.
Example of a global one is Alt+Tab. The root window is always listening to it regardless of which window is in focus.
Example of an application binding is Alt+Home in caja. The root window doesn’t know nor care about it, but caja is listening to it.
The HUD registers Alt in the first category, since otherwise we would need to add a new HUD to every single application. Now, since Alt is such a popular key, there are many bindings that use it, but the HUD has dibs on it, so whenever you press it the HUD reacts to it and grabs and locks the keyboard entirely (this is normal key binding behavior), then it just eagerly waits for those 250ms for the key to be released.
If the release happens next, and is within the 250ms delay, the HUD shows the menu and releases the keyboard lock for other inputs to happen. But, if another key is pressed before the delay ends (or even if the delay ends before Alt is released), HUD needs to decide whether to let the event through asynchronously, or replay it for the benefit of the application in focus.
Global key bindings (Alt+Tab) should be let through, as the root window is already aware of them being captured and things proceed as normal from there.
Application key bindings, however, were never let in on the fact that Alt was already pressed before someone else (i.e. the HUD) grabbed it, and so the event of “pressing the Alt key” needs to be replayed in the event queue so that they can see it. Here’s where things get fun. The HUD doesn’t know which keys belong in which category, but there are some clues: each keyboard layout has an internal map of keys that are used for input (a, b, c, etc.) and some that are used for controls (arrows, F1, Ctrl, Tab, etc.)
Usually you can just replay the former and let the latter through asynchronously, but things get dicey if you have an application that uses control keys in their bindings (i.e. caja with Alt+Home). That’s where the replay whitelist comes into play.
Since Alt+Home is (afaik) hardcoded in caja, you can’t really use it as a global key binding anyway. So replaying it is a good idea so that caja (and potentially other apps) can use it. Now, you also mentioned the pull down menus (I’m assuming that you mean the File, Edit, etc menus). Those are handled through normal input keys (e.g. Alt+f for File) which are already in the replay list. That means that these are not affected, we’re just adding new keys (home, left, right, up, down) to that list.
Note that this list is only used inside the HUD when used with the Alt key. If you change your HUD key binding this list is ignored entirely.
Hope this explains it 
Thanks for taking the time. I had pictured something totally different like a buffer dropping events.