We already have a solution for this sketched out on paper (not in writing or code yet, though). The idea is that the shell can split the terminal into "frames", where each frame acts as its own terminal. The shell would then use one frame per command prompt, and one frame per command (for its input and output). The stdin/stdout that is given to the command is restricted to that particular frame. It can then write text into that frame and move the cursor around inside it, but cannot break out of the frame, so e.g. it cannot overwrite the output of the previous command.

And once you have these frames, you can give them some useful properties: For example, the shell can fold them, or apply styling hints to them (e.g. so that a command with non-zero exit code can be highlighted with a red border or similar).

With frames, you can also have multiple commands running in parallel. For example, wget could signal to the shell that it will run for a while longer, but does not require user interaction, so the shell can allocate the next frame below the frame where wget is still running, and offer the next command prompt.

It also means that fullscreen programs do not need to block everything: vim may be running inside a frame that is set to the full window size, but you can just move the keyboard focus out of this frame and scroll upwards to review the output of a previous command while vim continues to run down below.