I recognise that this is an older post, but I feel there's something else to add.
For local players, the most important thing is input responsiveness. For remote players, something like EPIC would be a means of smoothing irregular updates due to packet loss. However, movement packets which are lost before the server receives them (in time) incur miscorrection on the server, for the next move (assuming that the lost packet contained changed inputs).
The only means that I can think to correct this is to send redundant previous moves to the server, (I.e 6 moves worth). If the server looses input for T 2, 3, 4 and receives moves for T5 +, it can use the last 3 moves to recover.
This will fix the stuttering corrections on the client, for this scenario.
Typically, it won't matter what the contents of the message are when you need to handle where it goes. Usually, you might prefix the message with an identifier (type) that can be used to select the appropriate recipient. The contents are then managed by the requesting handler.
If you're using JSON, everything is serialised/deserialised in one go, so this is less explicit in practice, but you can still simply define the message to include a type field, and the rest is up to the sender.
That way, you check the type field and dispatch to the recipient as needed. Creating a generic message that does everything every message might need is both a waste of bandwidth and development time.
Whilst I have little immediate experience on the subject, we had VSM shadows implemented recently, and a similar effect was observed.
The developer who implemented speculated (in passing) that the intensity of the light source was influencing the shadow