Design Discussion: Should control nodes immediately tick next child, or what until the next tick cycle?

[SteveMacenski]

Per ros-navigation/navigation2#4776 - we bring up an interesting question that I think is worth trying to get some general consensus in BT.CPP before updating application projects that use it.

When we have control nodes like Sequence, Fallback, or custom Bt nodes in other projects, should the next child be ticked immediately after a node returns the status required to move on, within the same tick iteration?

Right now, it does so in most cases. Davide added a async param for some of the control nodes that can be set such that it disables this behavior -- thus every tick executes one node, returns running, and the next tick could move on in the control flow.

I'd like to argue for a consensus that all control nodes only tick 1 node per iteration and explicitly return running at that point to be ticked again. That makes the flow explicitly introspectable and doesn't hide from logging what's going on in BT status updates. Further, it seems like the better explicit modeling to me (at least).

I understand that would make systems slightly less reactive since there would be a tick rate-sized delay before moving onto the next child. Maybe that should be possible to do, but I don't think it is the best expected default behavior.

I'd love to hear thoughts from Davide but also the broader BT.CPP community about: What do you think? Agree? Disagree? Not important?