Ok, the recursive nature of this combined with the event listeners i think is what is throwing me off.

So if move the event to fire right after the first line of the function (creation of the item) we can avoid iterating through the children IF the root item is not going to be shown at all.

For each child the listener will be called and has the opportunity to setItem(null) to prevent a child from being shown. Perhaps at this point it should stop propagation of the event (another event cannot re-add the item since its been set to null). To prevent a situation where listener 2 needs to ensure an item exists but listener 1 removed it users would just set priority on the kernel.event_listener tag to make sure the listeners run in the right order.

Regarding creation of the current node would not that be handled by the original event listeners that are called on the root node? They would just setItem(null) if the root node shouldnt be shown. In that case we'd never iterate through children.