the long answer starts with a question: what is the most reasonable behaviour of a node when confronted with an empty spread (Ø)? note that an empty spread is not a zero its no slice, no defined value.
we somehow thought an empty spread on one of the inputs should output empty spreads on all of the outputs. this makes somehow sense. no input = no output, just like 10 slices input = 10 slices output.
next is the framedelay. the framedelay takes the value from the last frame and outputs this in the current frame. if you form a loop you can store and change values iteratively. if you have no values at all and process them to get a new result, you still will have no values. so processing no values forms a stable loop - exactly in the same way as if you could have 10 slices staying in the loop (or just one, as it is the default case).
to recover from the empty spread loop lock, open up the loop and put default values in the input (alt-clicking on the pin).
yes we know there should be an easier way to do this.
as kalle said, eno patched a handy module, which calculates the Count of the spread, and if its zero, switches to a one sliced standard value. basically you can patch this yourself easily.
a cleaner solution would be to check when and why the empty spread occurres in the first place and take care of that. so put the replaceempty modules (or your way of doing things) directly after the HTTP input or whatever you have. make sure there is always a valid value and everything stays clear.