@minrk has a good point. Especially in JupyterLab, you could naturally do this with comms or with widgets, and basically you take responsibility for rendering the output when all the pieces come in (or partially rendering it, if you can...).
There may well be room for such a change in the base protocol (it has come up once before, to my knowledge), but it might be challenging, and the base protocol is a pretty conservative, slow-moving thing.
We sort of have precedence for it, in that we combine the stderr/stdout message blocks. That's more of an optimization, and different because each piece could stand on its own. But the final result is a block that trickled in over time...
You could imagine a new output renderer that was registered that preserved state, and had a new mimetype of application/jupyterlab-partial-mimetype
and encoded both the target mimetype and the part number.
or you may not have to preserve state if you had access to all of the current outputs in that particular cell.
(probably want to do application/jupyterlab-partial-mimetype+json to be able to encode the information better...)
But perhaps a better way is to do the decimation and summarization on the server side, and have a dynamic communication link with comms or widgets that would display the summarized data in the browser.