Actually the way forms are integrated with Stunner, so with both BPMN and DMN editors as well, is by callbacks - once a field is changed (and valid), the forms API runs a callback which delegates the execution of a command to Stunner.
Due to new requirements for kogito (channels), there is the need for exposing the ability to flush the foms state via API. So instead of forms calling Stunner, Stunner will use the Forms API to force flushing the state, which will update the underlying model as well, once the user saves the process.
The root issue which is causing the need for this, is properly explained by Pere Fernandez Perez :
the point is that forms are propagating the property changes into the model when they detect a change event fired by the widget (errai-data-binding world!), on textboxes/text areas this happens when the widget looses the focus. The big issue is that users on vscode can make changes on the properties panel and save the diagram without making the change event to happen.
This flush mechanism is only to force a flush to happen BEFORE the save on vscode is finally executed. So any pending change will be pushed into the model prior to saving the diagram.
So this is only the first change before the final integration in stunner and vscode extension is done.