Consider changing Prime.Ecs to a Sparse ECS.

[bryanedds]

From discord monologue -

bryanedds — 2:50 PM
this chap is pro-ECS in general, but quite skeptical on the archetype-based ECS design based on its higher complexity and overconsumption of memory bandwidth in his applications - https://moonside.games/posts/archetypal-ecs-considered-harmful/
I can't verify his position without writing a sparse ECS of my own, but 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.