Currently src/settings.js states:

// If 0, the runtime is not quit when main() completes (allowing code to
// run afterwards, for example from the browser main event loop). atexit()s
// are also not executed, and we can avoid including code for runtime shutdown,
// like flushing the stdio streams.
// Set this to 1 if you do want atexit()s or stdio streams to be flushed
// on exit.
var EXIT_RUNTIME = false;

If user passes -sEXIT_RUNTIME=0, does that mean

a) the generated code will never shut down, and no disk size will be expended to implement/track shutdown, or
b) falling out of main() will not shut down the page, but yield with a live runtime. The user can shut down the runtime either via explicit call to exit/emscripten_force_exit/dropping runtime keepalive refcount to zero.

In -sMINIMAL_RUNTIME, -sEXIT_RUNTIME=0 crystal clear means a). In regular runtime, it originally started out as meaning b), though it seems like the multitude of #if EXIT_RUNTIMEs in the src/lib*.js code seem to have kind of taken it to a direction of a) as well.

I wonder if things would be simpler if there were separate flags for these two usages?

Maybe something like -sEXIT_RUNTIME=disabled to mean that the concept of runtime shutting down doesn't need to be emitted to the web page (and falling off of main() should always yield), and -sEXIT_RUNTIME=yield to mean that falling out of main() should yield to the event loop, rather than shut down - and the ability to shut down later would be generated to the page?

One thing that makes things a bit more complex here is that in -pthread builds, the pthreads will need to have the ability to shut down at least enough of its runtime, so that the Worker hosting a pthread can acquire a different pthread to host later on.