So, I was about to write an explanation on why, but then, figured, might as well write an example on how to use events directly. 
You're correct, I haven't implemented any specific examples of using capabilities yet (which are extremely useful for this sort of thing).
Even implemented a "super" basic key blocking (only works for a single key at a time). Doesn't require any changes to the kll spec (even though I found/fixed a bug in the compiler while writing it 
).
Code changes.
https://github.com/kiibohd/controller/commit/398018ecf86bac3174d40b8cfb7d7321130759db
Using the "custom capabilities/actions" in a kll file.
https://github.com/kiibohd/kll/commit/5f8880d7efd7cc0abceb3543a03ba8db78135e7d
Just replace md1Overlay in https://github.com/kiibohd/controller/blob/master/Keyboards/infinity.bash to md1Action and run the script to try it out.
If you don't mind writing a bit of C code, it's possible to fully interact with all key states (Usually, just Press/Release/Hold but sometimes Off as well). This will also translate to Analog states in the future.
The clunky part here is specifying output USB codes. Due to a compiler/spec limitation it has to be a number (hex or decimal), but I can fix this in a future version.
Seems to work quite well for the Shift+Esc is ~ case. And can work for other single cases as well (simultaneous cases would require a more complicated C code).
Now, I'm not really sure if this is the best approach for this specific case, but it does work.
I inspected these new capabilities, than the MD1 Scan routine, and the Output routine later on, but still, I can't see a practical entry point to achieve what I want
I think this would satisfy a lot of basic use cases:
1) The ability to block the last keypress (I think you already have this, this is kind of a special case, because the last keypress is the actual trigger, for example the "Esc" in my examples)
2) The ability to manually release keypresses
3) The ability to manually engage keypresses
4) A Practical access to a blocking delay
(Even (1) is not ideal, ideally, it shouldn't be a "block", but rather a "catch"/"handle" event)
The Shift+Esc example was more practical, as the Shift is used in the end result too
But for "Ctrl+A" to "Cmd+Shift+B" for example
The routine would be
a) Block "A"
b) Release "Ctrl"
c) Output "Cmd+1ms+Shift+1ms+B"
d) Release "Shift+Cmd"
e) Re-Engage "Ctrl"
In this scenario, there will be a custom "my_custom_capability" function that the user writes, that calls the functions I mentioned in (1-4)
Both the scan and output routines seem simple, yet since I'm not fluent in the dynamics, I can't determine a practical entry point to add these capabilities myself
So basically, what I really want myself is to have direct access to the input/output logic as tmk_keyboard provides
I think it would even be simpler to write some basic C code than to learn kll, even for non-programmers, I've seen a lot of people edit/adapt code in a language they are not fluent in, however I haven't seen a lot of people that took the time to learn kll yet, everyone on the infinity drop waited years building their infinities as the online configurator wasn't working
So I know this might not be what you want to hear, but please add direct access to the input/output logic, practical methods to aid people in achieving edge things they want, rather than try to steer kll into edge directions (which should be extremely challenging)
(Edit: These might already be possible, but once again, the lack of examples make it hard for people to use them, as I see now, I might achieve what I want by calling Output_usbCodeSend_capability directly for release, engage stuff etc.)
(Edit 2: manually modifying bits and calling Output_send() seems closer at this point)
