Odpověď na názor

Na první bych reagoval takto: https://en.cppreference.com/w/cpp/compiler_support/23.html
- je tam prostě příliš mnoho červených míst i u clangu a gcc, a navíc na některých strojích mám ještě pořád gcc-13. Update asi přijde s novou LTS distribucí (nejspíš ubuntu). Takže je to praktický důvod. U jednoho zákazníka, pro kterého programuji dlouhodobě je aktuálně schváleno gcc-10.3.
A to je C++23. Nevím v jakém stavu schvalování je C++26. Ale support je ještě tristní: https://en.cppreference.com/w/cpp/compiler_support/26.html

- je tam víc chyb, postupně to opravím :)

Co se týče hive - musel jsem se podívat, jak přesně funguje - nejsem si jist, ale možná pokud bych zavedl archetypy, kde bych kombinace komponent přesouval do separátních poolů, pak by to asi šlo nějak použít.

Já tam aktuálně používám pro mazání strategii swap-and-truncate, tedy neděje se přesun všech prvků, jen jednoho. Ano, naruší to pořadí, ale zase to není velký issue. Výhodou je, že počet prvků zjistím tak, že odečtu end od begin, což se hodí, když se hledá pool s nejmenší mohutností. Pak je ještě výhoda v iteraci, že iterátor je vlastně random_access nebo aspoň bidirectional. To umožňuje range pro all_of<C> (enumerace entit dané komponenty) procházet náhodným přístupem. Oproti tomu samotný pohled (view<C>) už je input iterátor právě kvůli přeskakování. Jestli jsem pochopil hive taky přeskakuje, takže by se tam iterace maličko zesložitila.
Hive ovšem neřeší lookup, takže pořád potřebuji index. Index obsahuje pozice všech prvků - k tomu se právě hodí random access iterátor.