Its design principles are:

• "Flexible" does not mean "tries to do everything".
  • what it does mean is "any reasonable thing you might ever want to do with a one-liner AHK hotkey... we'll be able to do". That includes:
    • support FULL onKeyDown+onKeyUp remapping wherever possible
    • the ability to remap joysticks and mice
    • able to remap the mouse as well
    • the ability to create new shift-keys with various semi-standard semantics (possibly including crazy things like "take over the caps-lock LED to use for my own personal shift-lock key")
  • it does not mean:
    • control structures (loops, if statements, ...)
    • variables (though we will support environment variable-interpolation, so that we can use things like %windir%)
    • any hint that we're going to go ape-shit again and give birth to yet another half-assed permanently-nascent scripting language (seriously, if you ever feel in danger of stumbling down that route... save yourself (and the world) a lot of grief and pick an existing one... God knows the world has enough already) (of course, ignore that advice if you're dedicating yourself to researching a next-generation scripting language... but if all you need is some totally humdrum language to bolt on to some C code, and the C code is primary thing you're bestowing on the world, then PLEASE, don't confuse yourself with a next-gen-language-researcher)
• "Conceptually simple" means the "script" will be declarative rather than imperative. (it might be minimally ordered, similar to config specs, but for the most part, order won't matter at all, since every key is a one-liner)
  • actually... that specifically means it could be all GUIfied and shit
• Of course, the primary point of tension will be what "functions" we provide that can be triggered by a hotkey, since that will be the main limiting factor. These are the bare minimums:
  • keys
    • remap to another keystroke, of course (again, FULL up+down remapping) (we might include the ability to choose what method of simulating keystrokes we should use)
    • everything the current Send can do, PLUS the ability to do {sleep 50} right in the middle (when you do this in AHK, you have to break it up across multiple lines to do sleeps)
      • that includes clicking the mouse
  • menus
    • pick a menu item
    • pick a system-menu item
    • OPEN the system-menu (just because Putty is sorely lacking in this arena)
  • run a command
    • always start a new process, no matter what
    • check to see if an existing process is there:     if so, give it focus; if not, start a new process
  • control any of the various music-players (winamp, windows media, itunes), just because this is a pretty popular feature with everyone (including me)
  • change the volume
  • of course, when all else fails, niggas can just launch their own WSH script
• In addition to the above, the following things will be "special" ('#' prefix?) lines that do something other than define a hotkey:
  • #shiftkey — define a new shift-key, per my writeup
  • #IfWinActive/#IfWinExist — if it's possible to simplify AutoHotkey's syntax at all, then that'd be nice... otherwise, do exactly as they do (this is the ONLY part where script-order has any effect)
• (stretch goal) be able to show an on-screen keyboard of the various remappings as they change

Literature review

I'm sure this has been done a bunch of times before...

Wow... actually, would it be possible to just build our "formalize and abstract the shift keys" idea into an existing open-source product? (qliner hotkeys?) Some of them look pretty mature already.

Literature review (unrelated)

• DM2 — more "window modifier" than "hotkey magician"

Measures of success

• ("stretch goal") be able to implement non-exotic chorded keyboards (particularly half-QWERTY -- though if you need multiple layouts (de, etc), you'd have to just use a different declarative file for each layout)

Examples

caps lock on + c : Run calc.exe

Alternative implementations

• do it in AutoHotkey
  • implement and provide the patch for joystick-up detection (which should then make joystick-key-remapping possible? so provide that functionality in the patch too?)
  • somehow write custom functions to abstract some of the shift-key stuff out (how?.... a wrapper around Hotkey(), I suppose?)
  • maybe do the readable-shift-key conversion inside our wrapper?