Yes, though I'd want to add special detection for this case - to ensure that there are no runtime race conditions for having or not having a state from last fra

Yes, though I'd want to add special detection for this case - to ensure that there are no runtime race conditions for having or not having a state from last frame. No serialization occurs unless the message goes over a non-inproc transport (unserializable inproc only messages are possible, too!). I've considered this kind of idea before - I'd likely try to make it a first class citizen of the framework, in that case. Declare it in the definition for your node what kind of state it keeps, rather than try and shoehorn it into the pubsub system. I'd have some worry about the performance cost of it, though, for large states.