Hi, I posted a while ago an issue with removing a child node during a parent node's updateWorldData() method. The fix was put in place to catch the IndexOutOfBounds exception, but it says that it might miss a Node:
Thanks for thinking about this. 
First let me clarify when a child can be skipped: it happens only if a child is removed that is before the currently processed index. The only child that is skipped in this case is the direct successor of the child that causes the removal.
To solve this I would simply introduce a single field that is set on node removal (and/or addition). But it would require at least one additional field read access within the update loop (your solution has even more field accesses).
Because it is a very seldom case (and even discouraged to do it at all) we don't account for it because of performance reasons.
That's what I figured, that it was a seldom case, but the problem I think can occur more than one case, because say you remove more than one previous child while you are processing the current child.updateGeometricState(), then you could potentially skip more than one. I'm just trying to explain why I thought there needed to be an actual indexOffset variable because you could potentially need to offset by more than one.
IE: The * represents your current index The first row is the nodes themselves the second is the index number.
rootNode time 1, index=3:
A B C *D E F G H
0 1 2
impressive posts actually i didn't know about the removal problems, but will think twice after this…spanx!
too much time on your hands? i think we could find jme-subsections for you to nitpick that we really need to get picked and digged into
Yes, if you really face that problem you can mark or enqueue the children that should be removed. And remove them lateron.