Some background: I helped doing a remake of a mobile game called "Jamaican Discsta". That game in itself was a Drug Wars derivative.
Aside from the trade mechanics, there is a random event generator creating high probability events, medium, low and finally "chained" events. The possible events would vary by location and your "cool" statistic.
The interesting part is the "chained" events. Basically this would be an event X that had as a precondition that a previous event in the series was responded to in a particular manner.
For example, you meet a girl and have (in the first chain even) the possibility to flirt with her. If you don't, then the story ends there. If you do, then there are is a second event that may occur. If the correct choice is made, then this unlocks the possibility for a third chain event which lands you a special kind of record.
This was all very simple and the "one shot" random events would dominate. However, interpolating one could essentially turn most events into chain events. For example, in the third step of the chain, then the outcome of that will be affected by the outcome of another chain - one outcome if it happened but "failed", another if it "succeeded", and yet another if it never happened. By lifting conditions into "types of events" rather than particular events, the interaction between chains may display far more combinations than coded for.
That's the background.
So going past that, the idea is to allow the selection of chained events to be triggered by other players instead of randomness. A way to do this is to allow the game to run over multiple days. The actions from the previous day are then used to determine the (no longer) "random" events of your day.
For instance, consider an event where a criminal has gone on rampage downtown. The maffia boss will ask you to do something about it. This event will be triggered not by randomness but by one of the following possibilities:
a) a chain event in which another player's character goes on a rampage as result
b) a chain event in which another player's character causes someone to go on a rampage
c) another player exceeds a certain % in notoriety for their actions for the day.
d) some other player does a nefarious deed similar to going on a rampage
(these are just a few possibilities how to implement the feedback system - there are other ways as well)
The important thing here is that other players can generate a certain "human"-like behaviour to NPCs.
The question is how to make this translation from actions to feedback for other players. On one hand we could try for a 1:1 mapping: the players' actions appear directly into the games of the other players (within constraints - for example some actions might deliberately be omitted, such as A killing (in their universe) the player played by B will not translate into B dying in their own world, but the death might occur in the universes of A, C and D), or they're simply used as sort of randomness which still has a certain consistency, in that the actions of A, C and D will determine what events will be launched for B. However, those actions do not need to correspond to the actual actions of those players.
As far as I can tell, many systems are moving towards json for config etc. I can't speak for the rest, but I personally switched from xml (or xml-plists actually) to json because editing (and finding errors) is so much easier in json. Not to mention that json can be much more compact while still retaining readability.
Submitting fewer messages at a time leaves you with complete messages. Fragmenting data at a lower level (i.e. split up "binary data" agnostically of the message structure) will likely contain partial messages that can only be received by assembling fragments.
Insofar, doing this at application level is arguably cleaner and "better".
It does have the drawback that it breaks the abstraction. So now the application has to: 1) estimate packet size - meaning it must know the details of how the serialization works, 2) query the networking layer for maximum packet size and 3) add code fragmenting and defragmenting updates at various places (been there, done that).
It also means that any change in the networking layer might suddenly touch a whole lot more code than just the parts directly related to networking.