After going through all the code for this, I think Spawn may be too specific,
we could include entity(Entity) -> Self::SpawnOuyput as well, since it shares the return type,
but we'd need a better name than Spawn

I'll fix docs after we agree on the code, it's a pain to maintain at all time

Not a full review yet but one note: Since Spawn::SpawnOutput is not given any bounds, generic contexts won't be able to do anything besides return it:

fn foo<C: Spawn>(commands: C) -> C::SpawnOutput {
    commands.spawn_empty()
        .insert(...) // Error
        .with_children(...) // Error
}

This would require another trait, so if the plan is to do that in a separate PR that makes sense.

I'm getting the easy traits out first, hopefully we can get a few in 0.14.1

The trait for EntityCommands and WorldMutEntity is pretty controversial imo, since the mutation would be either deferred or immediate and that's something to consider

Deferred vs immediate is already the case for Commands as Spawn vs World as Spawn, no?

Naming proposition:

• Spawn -> EntityContext
• Spawn::SpawnOutput -> EntityContext::EntityBuilder (and later this will be bound by a trait named EntityBuilder)

Or something along these lines. Issue is, EntityContext can be interpreted as either a context where you can interact with entities, OR the context of a particular entity (which would actually be EntityBuilder).

I want to see a more cohesive overview of which traits would be used, and what they would be implemented for. I don't think this is wise to merge piecemeal, although I am in favor of the broad idea.

If we can't do it piecewise then this will turn into a large scale PR that will need to be for 0.15, in that case I'm closing the issue in favor of future discussion in #14231 with this as an example