Might seem like odd questions, but is there a plan to handle the "too much data" case? and how protocol agnostic can this be? This seems really cool, and I can think of some strait forward uses for it ... but working on a satellite project where communications are 75% of the hassle, this sort of thing seems like it could be very useful...
If it can deal with all the "weird" (its very normal for space, just not used anywhere else) batched radio communication standards from the Consultative Committee for Space Data Systems (CCSDS) then intermittent communications aren't as big of a problem.
However it will also need to handle "old data that can be deleted client side". A satellite will generate a lot of data that it doesn't need to keep but will want to transfer to the ground and keep on the ground, telemetry and tracking metrics, system statuses etc. One way is to keep all this buffered on the satellite, and transmit to the ground, then you can throw it away, etc.. But having a synchronised store is a much simpler programming model, you push important data into the store and let it look after itself, and simple code is easier to make more reliable and reliability is key for anything in aerospace. However it can't result in the remote device being "full", it's a 100% non-starter. The client/remote end has to be able to throw away old/expired data while the central store is able to keep that data, without requiring awkward secondary systems polling the latest state on the ground side to save current data into a separate system to store historical data, that would just be shifting the complexity around.