Much better docs, and I really like the closure based API. Why not bake this in directly to EntityMap? It's unclear when you would be okay to forgo the guarantees provided here.

I'm not sure I see a good way to do that that both preserves safety and doesn't make the API more awkward. Baked into EntityMap we either have an extra bit of state (has a dead_start or doesn't, making dead_start have to be Option<Entity>) or we push the initialization and saving out to code setting up the EntityMap. In the first case, the result would be get_or_alloc either panicking or returning Option<Entity> instead of entity. In the second we can't use the closure approach to ensure safety anymore. Also in the first case, it becomes possible to bypass with_mapper.

Making this controversial because this is taking scene ids in a new-ish direction. Scenes should have "virtual self contained identity spaces" that don't (necessarily) correspond to real world entities. Introducing generation (especially for "top level" entities in the scene) makes the scene format longer / harder to read and compose (just look at the diffs in the scene files). Generation isn't a useful part of the of "scene mental model". Introducing generation also encourages people to think about "runtime ids" as the same thing as scene ids.

There is definitely an issue in the current approach when it comes to uniqueness. ( id: 4, gen: 0) and (id: 4, gen: 1) should not be considered the same thing. And dangling ids should be accounted for.

Some alternative ideas to consider:

• Serialize scene entity ids as u64s (laid out as [id_u32][generation_u32]). Treat that as just a simpler encoding of (id: u32, generation: u32)
• When serializing, just create a brand new Entity->SceneId mapping and allocate new SceneIds as new entities are encountered.

Curious what the reflection SMEs think: @MrGVSV @jakobhellermann

• When serializing, just create a brand new Entity->SceneId mapping and allocate new SceneIds as new entities are encountered.

This is very difficult to do because we currently can't look inside components with entity references when serializing, and so we can't allocate SceneIds for dangling references nor serialize component entity references as SceneIds. It would be a much, much larger change to start doing that. The entities in dangling references are only encountered when adding a deserialized scene to the world and no sooner (after both serialization and deserialization).

• Serialize scene entity ids as u64s (laid out as [id_u32][generation_u32]). Treat that as just a simpler encoding of (id: u32, generation: u32)

Amusingly, this is actually what the initial version of this PR did (well, almost: it was [generation_u32][id_u32] since it used the existing Entity::to_bits()). Check out the now-resolved thread off the first comment alice left on dynamic_scene.rs.

I think it makes sense for Entity to serialize like this everywhere, so that both component entity references and the top-level entity IDs serialize as u64s. Though, I was going to put that into a separate PR.

(moved back to the 0.10 milestone, but it might be too late at this point so no promises!)

Moving this to 0.11 as it seems like we're going to be shipping 0.10 early today, and this isn't ready yet for a merge.

and this isn't ready yet for a merge.

But looks like comments were addressed. Or you mean that the approach is controversial?
I just think scene loading can't be broken more. This PR fixes a pretty serious bug with scene loading.

Need to resolve conflicts and this seems ready for a final review/merge, right?

@Illiux I started using this new approach and found mutable world access inconvenient for the MapEntities trait in practice. And it causes huge impact on performance if you map many components.
Mapping entities is useful for networking. Yes, I can create my own trait that just returns error on incorrect mapping (to avoid world acess), but this mean that I have to create two derives for component/events: one for networking and one for scene serialization.