Thanks so much for all of this. It's extremely well put together. I'm still trying to figure out the optimal way to organize every part of a Dwarf Fortress-style simulation (but multi-threaded of course), and I feel like I'm reinventing the wheel somewhat poorly. Component-based design is an important part of that, but there are still so many hairy problems to solve. These are problems which most games don't encounte…
One place this is likely to break down is the transform (position) component, but one strategy for that is to differentiate between read-only and write access. Lots of systems need to know where things are (const access) but few need to change where things are (write access). All the systems that can deal with const access can still run in parallel.
The trick here is you have to strictly enforce all this. You CAN'T have a method for getting an arbitrary component from an entity, and this may drive you nuts. Instead you have to have each system specify ahead of time exactly what components it needs and how it uses them, and then hand them those components, and only those components. As soon as you let someone write "entity->GetComponent(Physics)" in leaf code, you've lost your ability to analyse the dependency tree.
For a lot of games, the other problem you're going to run into is that one or two systems are going to take up most of your time and every other system is just going to sit around waiting for those anyway. Usually those are physics and rendering. Which you might be happily avoiding by making a dwarf fortress style game!
I have a coworker who's got a "toy" engine at home that does all this and some other fairly amazing tricks. He says he's going to open source it, still waiting on that. Sorry for this pointless tease, just wishing he'd hurry up out loud.