However, this is not part of the original post because no parent / child events are present.
Perhaps you're referring to the primary event that calls the loop as the parent and the actual loop execution as the child, but then it would probably be better to not use the terminology parent / child events.
Further I think that Clickteam participants in this thread are referring to Fusion's internal selection process as scoping.
For me, scoping is isolating or selecting a list of objects, out of a set of objects, and no scoping takes place when all objects are selected - but I guess that's just semantics.
What you're saying is that Fusion doesn't know what changes were made, and therefore breaks. However, the initial objects were not changed, they're still there - there was no modification.
Index 1 - Object A
Index 2 - Object A
Index 3 - Object A
Index 4 - Object A
Index 5 - Object A
Mark Index 5 for deletion - run the loop that creates more Object A
Index 6 - Object A
Index 7 - Object A
Index 8 - Object A
Index 9 - Object A
Index 10 - Object A
When Fusion comes back to the destroy event it now marks index 10 for deletion and then stops. If, Fusion failed to add Index 6 - 10 to the list, i.e. it does not know what modifications were made, it would then still correctly have
deleted Index 1 to 5. But it deleted Index 10 and then stopped.