This example focuses on the new Network Process (NP), but the issue will affect any core service that is new or carved out of browser process.

On first run, or any time, that a core service child process is spawned, how do we want to handle a failed service startup?  (And what is the user experience?)

In the case of the NP (--enable-features=NetworkService), if the child process fails to be spawned or successfully initialized:
1) the browser UI remains visible and open.
2) because this service is "restartable", it appears an infinite loop of attempted child respawns is happening under the hood - constantly chewing system resources.
3) the visible browser does not appropriately shutdown due to critical failure... it just sits there with no networking under the hood. (Not ideal user experience, and possibly no appropriate UMA visibility for us back in-house?)

Even if the NP wasn't "restartable", I think the visible user experience would be the same, just without the hidden infinite failing spawn loop.

When core functionality like networking was part of the browser process, any failure to initialize would result in a browser shutdown.  I would expect to at least see that here.

We should have a cohesive strategy and reaction for all "core" services (is that indicated in the manifests?) that Chrome needs to have running.  We definitely need a failure path for the NP before we start experimenting on early channels.

**I think this is a cross-platform issue (though I'm only testing on Windows).  
Feel free to adjust all triage labels!  It might be a P1 relative to the NetworkService progress.