When nodes are entered they are handled considering whether or not they are already running. A sequence node, for example, would not restart if it is running. I think that would do the trick.
But then none of the sequences on the way to the current node will be evaluated, because they are all 'running', and the BT won't be able to react to changes...? And same with Selectors.
It seems like a strange idiomatical issue. I think the "what to use in which circumstance"/"what to use" could be assumed because of context.
What I wanted to say: Problems like the one mentioned in the OP may occur because the one tool at hand is not suitable for the job. Splitting the problem into sub-problems and using the correct (whatever that means in the given situation) tool for each one should be preferred.
When nodes are entered they are handled considering whether or not they are already running. A sequence node, for example, would not restart if it is running. I think that would do the trick.
But then none of the sequences on the way to the current node will be evaluated, because they are all 'running', and the BT won't be able to react to changes...? And same with Selectors.
Nodes work accordingly to their type. A selector node is allowed to work another way than a sequence node.
There's no standard for behaviour trees, as far as I know; I've seen some people implement them starting from the root every time, some people only go from the root when an explicit re-evaluation is needed, and I've seen compromise approaches where the last decision was cached.
If it helps, consider the behaviour tree to be deciding the behaviour - and if the behaviour you decide upon this tick is the same behaviour you had decided upon in the previous tick, then the behaviour does not have to be changed, which means its state persists.
An update, one way I've seen this solved, is marking which nodes are "interrupting". This means that these nodes will be evaluated every tick (if they are in the path to the current running node), while other nodes will not.
Funny thing is, in all the articles I've read that describe how behavior trees work, and even those implementing them, no one mentions this issue... It seems like a kind of problem that everyone would encounter.
Such an attempt to solve the problem is discussed here: Synchronized Behavior Trees
(BTW: That article also states my own opinion, that BTs are fine to execute elsewhere made decisions :))
After a tick of walking to bed, the ai is no longer near the door, so next time the "walk to door" node is ticked, instead of returning success, it will walk the AI back towards the door and return "running", until it is back at the door.
These actions would be placed under a sequence node. Therefore, all the actions would be ticked until completion one after the other. There is no going back to a completed action. So when the AI start the "go to bed action", the previous actions have succeeded and are completed, the sequence node won't tick then again. So the AI would go to bed as expected, and won't get back to the door (unless the sequence node is re-initialized and restarted again).
