I think this is where I'm failing to understand how this is going to work with multiple events because if events are responsible for adding the children how are the events going to avoid adding children that other events might NOT want added?

I guess if an event was going to set the children itself it would have to stopPropagation because otherwise it might add published children and then another event would add unpublished children because it doesnt know about the logic for published children. So that would mean that only event 1 got fired. Perhaps I am misunderstanding.

Why not just create the item as normal and then let the event get called which can decide whether to modify the item (set it to null for example). If there is no root item it will return and no children will be iterated over. Otherwise it will iterate over each child and perform the same logic of allowing the listener to determine if it should be added or not. This gives each listener to opportunity to null out the item.

I am recalling now another reason why I moved the event to after children are added which is for the dynamic menu code I added being able to insert items at certain locations in the menu (it cant insert it at the end if it adds them before the children are added). This may not be a big deal.

I do think that having an event be able to cancel child adding is going to cause issues if you want to have events be able to determine whether items should be added based on different criteria (due to being published vs. due to user having the right permissions).