I have a couple questions about the design of the threadpool that somewhat tie into potential future optimizations too:
First off, why is it limited to 31 (or 32 with the main thread) threads? If it's because of the processor group limit on windows (wherein one group is at most 64 logical processors and therefore 32 physical cores), would it not be desirable to add support for spanning threads across multiple processor groups?
Secondly, why is the thread pool an explicit singleton? This design/architecture of this threadpool seems like it could work very well in uses like event loop handlers or reactors that want their own pool, if multiple pools could be created and customized.

No real reason for it. The project is still very early on and some features will get polished over time.

The current idea was getting something reasonable done that would suit the needs of the project and could be built upon later (e.g. parallel/async execution will need to be supported natively by querries at some point).

Getting a threading API right is not something that is done over night.

I am expecting things to change as the project evolves and adapts to various needs which users have.

Any suggestions are welcome, of course.

That's fair! I do think it would be interesting and potentially useful to make the threadpool more flexible like that (by not forcing it to be a singleton), but at that point it's not necessarily in service of the ECS exclusively, and it also makes it easier for users to misuse it, so a bit of a trade-off.
As for the thread limit and especially the mention of processor groups, it was more a personal curiosity, as I've noticed a lot of other popular thread pool and task executor framework implementations don't handle those either (and as someone that does use a windows machine with more than one processor group, I wish more did!)

Ability to properly use multiple CPU groups and also big.little architectures is one of the goals.

Some groundwork has already been laid in 0.8.4 via introduction of task priorities (high for perf cores, low for eco cores or downclocked perf cores). This makes use of QoS on platforms that support it (win, macos) and scheduling priorities where it is not.

In the future I would like to build on this system further.