It’s all very situationally specific to what the process does and how it should handle failure, so if you have a specific example?

What if the current state or msg queue is the reason for the failure? One central requirement for the self healing properties of the beam is to always start a process into a known to work state, which you don‘t do if you keep state or messages around.

This requires the fact that you can safely discard messages, so it doesn’t invalidate the following messages.

Also keep in mind that a process might be restarted not because its own state/queue had problems within the process boundries, but it might be part of a bigger supervision tree, which doesn’t work with the current state and therefore some supervisor above the current process does initiate the restart. So to your process things can seems very fine, but if another process has problems with your process’s state you still need to have a way to resolve the problem.

IMHO this isn’t that much a common need and unfortunately the devil is in the details. I’ve had coded this maybe trice and each instance there wasn’t much commonality besides the grand idea of storing/restoring state.

I suspect you would be hand-rolling your own solution.