Notes:

The input and output modes are global state, and while we're thinking about what it would take to change that we're definitely concerned about backwards compatibility.
When an application exits and leaves the console in a state different from the one it has when it launched (which can happen for a number of reasons: it wasn't authored correctly, it crashes, it returns control of the console so the shell before it's ready (#4921)), we have little choice but to get into a weird state.
You see this with most terminals on the market, unfortunately. If vim is running in mouse mode, and is abruptly terminated, suddenly moving your mouse over your terminal generates an absolute heap of garbage input. It's impossible to solve in that case, but given that we own the console subsystem in its entirety we can put together a better story.

We should investigate our options here: can we make the input or output mode process state?

If we make the input mode process-local, we need to move to an input model that miniksa and I have discussed: input records are translated (mouse -> vt, input -> vt, clipboard -> key, or clipboard -> vt) for the reader instead of upon insertion into the queue. That's a huge chunk of work.

Making the output mode process-local may have many fewer caveats. We already have some process-local output state like UTF-8 partials.

This'll solve the overarching issue in #4921 and #4949.