"Edit-mode Destroy() is deferred — scene queries return stale objects"

An editor tool that rebuilds a world root each call (previousRoot.Destroy() then build new) appears correct — scene_tree a moment later shows exactly one root — but a scene query fired right after the mutating call returns stale objects from the prior build. You see species, props, or components that no longer exist in the current data, producing an impossible-looking contradiction.

In edit mode, GameObject.Destroy() is deferred. The editor scene doesn't tick like play mode, so queued destroys and query caches settle a beat behind the mutation. A query issued in the same call stack as the destroy reads the pre-destroy snapshot.

Corollary: edit-mode lighting for runtime-spawned ModelRenderers is also unreliable — unlit/near-black across regenerates, no shadow cook. A scatter that looks black in the editor viewport can be perfectly lit in play mode.

1. Don't trust a scene query issued in the same breath as the mutation. Either re-generate and re-query in a separate step, or drive the same build in play mode where lighting and object lifecycle are real.
2. Verify colour/lighting in play mode; verify data/audits from the census — not the editor viewport.
3. If you must query in edit mode, add a delay or re-trigger the query from a separate editor action after the destroy has settled.

Play mode ticks the full scene lifecycle (destroy, create, enable, render) synchronously each frame. Edit mode defers destruction and caches query results for editor responsiveness, creating a window where queries lag behind mutations.