It seems like most feature requests are things which were available in our earlier Gordius Little Giant controllers, and deliberately left out to keep the complexity down
For the delay command in the Little Giant you had the choice between a blocking delay, non-blocking delay, long-press delay, long-release delay, (absolute or clock-synced delay) ...
I remember it was quite complex for the user to get it all programmed correctly. Same for UnO2: everything which can be linked to a switch (preset, effect or trigger) already has a "short press" action, so you would have to do special tricks to combine that with a long-press action.
The up/down switches in UnO2 already have a long press action, which is too obvious to abandon (start auto-scrolling banks up or down)
Implementing a non-blocking wait is easy, but of course the complexity is that you want to do other things during a non-blocking wait. At the end of the wait the controller needs to process the rest of the original preset contents, while you might already have activated another preset in the mean time, so which one is active then? and so on...
I did introduce this "programming language" concept, because it allowed adding more features without making the editor more bloated (I remember the hundreds of checkboxes and dropdownboxes in the LittleGiant editor, growing after each firmware release) , but now I'm convinced that an ever growing command set might be as bad. I already get plenty of complaints about the learning curve and stuff like "this sucks, when will you release a graphical editor"... (never!)
