In my opinion, gameplay comes first, then we imagine software to make it possible. I mean that building an angine to enable compact crowds of players with collision & physics simulation don't looks like enough to define the player experience and what really matters. Is the compact crowd (public transportation like) even something desirable to provide a good experience? If not, the issue should be dealt with before (disable collisions in crowded/marketplace areas)
And if you need that in the game (large scale -interesting- close combat battles?), I doubt that a generic engine would do.
That mean a lot of testing & tweaking, keeping in mind that what's important is not accurancy but player experience according to the gameplay mechanics. Players everywhere would mean that individuals loose significance. That's not PvP, but Mob vs Mob. Maybe some sort of LOD with precise local interactions then working with densities and statistical behaviors at longer range to reduce the quantity of informations required. In this case you have to deal with the issues listed by hplus0603. At the end it depends on the game's priorities and compromises.
PS: I have met web architects advising to use simple stateless loadbalancing for realtime multiplayer with Redis to manage send queues and game state. If you need physics or whatever, it won't work. Too much latency, and that's not Redis fault. The software is fine but not made for this. In my opinion, that's shoe horning REST optimisation into something which cannot be made stateless. Because there are to many player interactions. It works for chats however because: 1) There is not so much user interactions 2) latency is not really a concern.
But that's not the what I meant: Many companies died by designing something which was way more complicated and beautiful than what the actual need required. So without clear goal & specifications, we (myself first) tend to overthink things.
