Fair, it was probably a bad specific example. The general point remains that a container can leave behind inconsistent state (lockfiles, application level stuf

Fair, it was probably a bad specific example. The general point remains that a container can leave behind inconsistent state (lockfiles, application level stuff in shared volumes, whatever). The larger point is that if something broke by container going down, it is not necessarily solved just by container going back up. Satisfying boot order requirements is another example. The system relies on the "pod healthy/not healthy" contract, with pod-level restart as a fix when unhealthy; Introducing a spectrum of readyness like 'half-broken-but-internally-attempting-rebuild' would make everything more complex, both for the orchestrator deciding when to reset, and for the dev who no longer has a single point of entry for 'make sure that we're ready to go'.