Consider changing Prime.Ecs to a Sparse ECS.

[bryanedds]

The current Archetype ECS in Prime is interesting but perhaps too sophisticated for games that have a lot of dynamic entities.
The resulting archetype updates and bookkeeping could make things a lot slower than a simpler Sparse ECS implementation.
Here's an actual comparison study - https://diglib.eg.org/server/api/core/bitstreams/766b72a4-70ae-4e8e-935b-949d589ed962/content
I can see that if one is trying to use an ECS for as much of a game's representation as possible, a sparse ECS might be a smarter approach.
We maintain an archetype-based ECS for a different purpose - as a possible complementary solution to an existing engine's entity representation.
But I'd think that it'd be more 'useful' if it were changed to a sparse ECS because the archetype-based form really has no use alongside Nu.
At least a sparse ECS would have some hypothetical use as an alternative to using Nu.
Tho I still think that ECS's are generally not the right approach to game dev.

[bryanedds]

Perhaps one could also provide an ImSim-like API for our ECS if the following were true -

1. Lenses were defined in component-specific namespaces / modules, like - Transform.Position.

This way there wouldn't be ambiguity among components fields with the same name.

2. There were a data-driven way to specify which components an entity currently has.

That way, components could be added and removed based on a declaration.

However, in the end this also would be basically useless because often the types of entities you want to use this approach for are hierarchical, like UI and character controllers - and an ECS just isn't going to be a good representation for those hierarchies.