As an aftermath of writing topic, while staring at n-modules/Window#Events (Coming soon™) and struggling with my own hotkey issues, I thought up an idea, that may change the future of LiteStep and redefine the term "extensible" on a whole new level.

I'm talking about adding ability to define reactions to window messages in the litestep config.
The basics are rather simple.

1. Define a list of known messages and virtual key map. Simple "string int" pairs list.
*MessageList "$LSConfigDir$\winuser.txt"
*VKeyList "$LSConfigDir$\vkeys.txt"
You can define any messages (even feed whole winuser.h), but for security purposess standard system messages (msgId < 0x0400) should never reach the userland.

2. Add some action defs:

• Main one:
  *On MESSAGE lParam,wParam !Action
  MESSAGE can be
  

  1. a string constant from MessageList

  2. quoted LS variable evaluated to a string name

  3. number

  4. LS variable evaluated to a number

  lParam is a simple number, wParam can be anything sensible, or a literal unquoted "*" to accept any wParam.

• Since messages below 0x0400 can't be caught, it needs a special way to catch keystrokes. Besides, it doesn't make much sense to handle input messages on such a low level. Consider it a shortcut if you wish.
  *OnKeyDown key[:modifiers] !Action
  *OnKeyUp key[:modifiers] !Action
  (Note - these are NOT hotkeys. These are simple keystrokes that user perform, when the corresponding LS's window is active.)
  The reason to compound modifiers with the key is the clarity of configuration file. You don't need to write "none" or anything to that extent to signify absence of something. Just… you know… don't write what you don't need.

• An alias to either *OnKeyUp or *OnKeyDown
  *OnKey
  and…

• …configuration directive
  OnKeyDefault [ OnKeyUp | OnKeyDown ]
  …will let users decide if they want X.Org or Windows behavior for their keystrokes without rewriting whole blocks of the theme.

• Finishing with configuration part, technical implementation would be to set up a window with specific class and name, then process messages sent to it and pass the event to respective actions.

See, where we are now? You can do something with keys! (Like you weren't able to do that before…)
But that's not the point of change. With (almost) direct message processing on LS's end, you can nicely ask LS to do something without keys!
I.e. bind LS action (bang command or whatever) to a custom message, and send that message from application written by yourself.
There's a good handful of different languages you can write a Windows application in, and not all of them are suitable to write LS plugins.
Someone might say "I can just start ls.exe !Bang and it'll… erm… bang!"
I'll tell you, that to start something, you gotta know, where that something is located.
The truth is, when you tell your kids to cease the fuss and go to bed, their location is the least important factor. Same for interprocess operation. All you REALLY need to know, is that there's a window ready to accept your messages.
If there's a window "LiteStepEventHandler 1.0" floating in the system, it is ready to accept your messages. Will it react to them, and will its reaction be useful - is a completely different question.

Where this can be used "in real world"?
Remember I mentioned struggling with hotkeys? The issue is rather simple. When UAC is enabled, and there's an elevated window in foreground, most of hotkeys just don't reach the LS. Only hotkeys that include Ctrl+Alt propagate outside the elevated canvas.
Well, there's a way to escape the jail… yes, you guessed it - become the jailer! Or break the jail. Okay, okay, we are not breaking anything today. So… You need an elevated application to register hotkeys, which will be unaffected by the elevated status of other applications, as they will play on equal ground.
However, there's an inherent security issue. You do not want to run your shell elevated.
Solution would be to have a proxy, that will register hotkeys on system level and repost them to LS as either ordinary keystrokes or custom messages, which will then be processed into actions "as normal".
That's one example. I think you can make up some more.