Internals
95% of Windows applications read keyboard in "common way" and can not recognize different keyboards. Windows don't provide information which keyboard was used by default. Windows support additional "low level" way how to read keyboards and using this way keyboards can be recognized.
So luamacros is using this additional low level way to know on which keyboard you press the button. Having this info luamacros can run the macro you define in lua code. Now as this low level way is kind of "additional" and luamacros just listen and behave silently in the background the biggest task is to prevent original key press to arrive to active application when luamacros started some action for this key. For this task luamacros needs to inject small piece of code to active application (the one receiving key presses). This injected code can pause this "common way" how most of application receive key presses and ask luamacros program if it triggered some action for this key press. If luamacros used this key press to start some action the key press is blocked by the injected code. If not this injected code just pass the key press to active application.
The problem is that this "hack" works only for applications that read keyboard in this most common way. Even if this applies for most applications there are some programs that are not using this common way and for some reason they use some more direct or "lower level" way - e.g. the same as luamacros. These lower ways can not be blocked by luamacros so what happens in these programs is that even if luamacros start some action on key press the original key is still recognized by active application.
There's no way how luamacros can block original key in these applications or I don't know it.
All actions triggered by various inputs (key press, X-plane value change, data on COM port) are lua functions. You can place any lua code in this function/callback/handler so it may happen it runs for some time. You can also put intentional delay in action handler.
So what happens if some handler should be started but another one is still running? Lua handlers are queued and don't run in parallel. So if your triggers come too often and callbacks run too long the action handlers to be executed get queued and if the queue size limit is reached (currently set to 50 items) the callbacks start to be ignored. Current queue size (=how many callbacks are waiting to be executed) is displayed in status bar
