Thanks for the input! In actuality, the slow light is the coat of paint (the renderer), the simulation layer happens in a true-state layer that is hidden from players (but observers watching a game can toggle it on) - there are also some abilities in game that show the true-state. It follows real physics because the dynamics is Newtonian (no relativistic effects since we're operating far from the speed of casaulity which is light speed in a vacuum). In my game, light is slowed down to 1/10th the speed of sound via a ficticious atmosphere with an enormous index of refraction.
As for your other concerns, yes I agree the ping needs to be visible and it indeed is a faint arc visible emitted from command structures and connected relays. I can probably add a toggle to adjust opacity and brightness of it since it can be a bit annoying if you have high APM!
For multiplayer, the game would simply update the true state to everyone's backend and then compute the delay perception locally. The way it works is that all entities in the game have vertices (most units store 4 position coordinates (corners of the sprite) but larger units can have more) which carry history information which is updated every 0.05 seconds (the sim tick rate is 20 Hz). Basically, there is a large ring buffer for all vertices that is precomputed to the length of the maximal delay (which is the map diagonal divided by the speed of light, or about 30-45 seconds roughly). And every vertex stores state information such as HP, position, alive/dead flag, ammo counts, buff/debuff flags, etc. This is how the magic happens and how you can see the past in a dynamic way since the backward light cones of all your units calculates the earlier states as needed for everything by using a delay field calculated over the entire map.