Absolutely!
In essence, the two features that I'm thinking of are both about giving the screens and their widgets some pre-existing logic according to type, and the ability to feed arbitrary parameters into that logic.
TouchGFX has great support for taking simple inputs from the screen and passing it to the ScreenView class (both since it is possible to invoke virtual function calls, and executing inline code directly). However, since you need to know about all the widget names, their types, etc. to integrate them with an underlying app, this mostly only helps to interface GUI with existing code for single widgets.
When you're working with displays lacking touch-capabilities, you lose most of the widget-output that normally serve as stimuli. That's when the binding to specific widgets become very apparent, and you're forced to know exactly what's being put into the designer before even writing your code. The reason for this is that most of the widget logic seems to be encapsulated in the TouchGFX binaries, and so is not available for additional logic.
So, in summary, the feature that could be added here is the ability to create new widget types that would be exposed in the designer - where developers can tailor type-specific code attached to every widget of a given type. Then you can create bindings in advance, without having to know about specific widgets.
Also, taking that same idea (exposing new types in the designer) but applying it to interaction triggers as well would give a lot more flexibility in creating input from the underlying app. As stated earlier, the "Hardware button is pressed"-trigger is currently the only useful way of creating an event handler.
By allowing developers to define their own interaction triggers, it would make it easier to provide late binding in the development process, and allow for more flexibility in the designer.
Furthermore, the "handleKeyEvent"-trigger already provide an 8-bit int as parameter. It could be extended to cover other types. Combined with widget-type logic, it would allow much more of the work to be done in the designer.
One example I would imagine of the above could then be the ability to create a widget with predefined functions that take the parameter of an associated interaction trigger. Say, for instance, widget A taking a boolean from interaction B to execute a method C.
EDIT: All the widget logic may not necessarily be enclosed in binaries, but the point being that they are hard to modify or extend.
