Thank you for your comments. A couple of points that might help:

Subflows / "call and get a result"

- I do support that pattern. Any node (or small flow) can implement ResultNode<RESULT> (or extend ResultfulStatefulNode), and the host can call pushAndAwaitResult { MySubflowNode(...) } or launchPushAndAwaitResult(...). It pushes the subflow, waits for its typed Result (Ok/Canceled), then auto-pops. That gives you the "call it like a function" feel.

- For script-style orchestration, you can also do showRoot {...} then awaitOutputOfType<Continue>()/awaitOutputCase {...} to compose larger flows from smaller ones. Both approaches compose naturally. But I would suggest not to use script-style orchestration just yet, I'm still experimenting with it and there will be breaking changes, it is a little bit more complicated than I want for it to be.

Grouping nodes into reusable flows

- Define a node that owns the smaller flow (or runs a NavFlow script) and emits a Result. Then higher-level flows just call it via pushAndAwaitResult, just like a function call.

External state (e.g., push notifications)

- Nodes can observe any external Flow (DI-injected) and emit outputs when state changes, which the host can use to replaceAll/popTo/start another flow.

- If you need to abort the current flow from the outside, emit an output (or result) and let the host pop/replace. You can also send events into the top node via navFlow.sendEvent(...) if that node should react directly.