What I would love to see is a terminal that builds it’s own shell from scratch too rejecting the ancient ideas we have with bash. I still love bash but I’m curious what could come of it.
Thinking about it some more I am not sure that we would have to go that far. Well not in the longer term - short term we might for experimenting with ideas. I think one of the bigger problems ATM is the terminal does not understand what a shell is or its component parts. Terminals just display characters and move the cursor around the screen and send keyboard and now mouse input back to the command they run. They are also aware of alternative buffers and raw input mode and know about echoing characters back the the screen.
If we extended the terminals to also understand some shell concepts like the prompt, commands being typed and output from the commands and gave the shell some markers it could send along with these (like we do with color information ATM) the terminal would be able to use these to change how it displays each part and would open up a lot of new an interesting features. Could even add things like tooltip support or actions on clicking some bits of the text.
I am starting to see these terminals as experimenting on what we features could be enabled if we were not stuck on the current VT100 protocals. Though if we ever get wider adoption and generalisation of these ideas backed back into the protocals will be another question to consider.
REPLs are basically shells. They behave the same way in every essential way. So the real question is support vs non-supported shells. But then that is easy - non supported shells fall back to just what a normal commands do ATM to process input/output. Other applications like TUIs are also easy to deal with as they already enter a different mode called raw mode - when a application requests that it can do what they currently do - switch to a new buffer and give full control to that one application.
Having smarter scroll back that knows the difference between a prompt/command and the output would let you do quite a few things that would be nice to have. Such as collapsing the output so you can only see the commands, keeping the command at the top of the screen even as other output scrolls off the top so you can always see what was running. Extra support for other UI elements could be nice to have as well - like tooltip support for blocks or similar.
All the shell - or really any application - needs to do is tell the terminal which bits of the output are witch. Like mark the start/end of the prompt, command and command output. Then the fallback is basically ignore the markers and print things out like it currently does.
And those are just random thoughts I have had over the last few days. These can be implemented in backwards compatible ways I believe and don’t need special support for specific shells - just needs to expand the VT100 protocols to be able to send more information between the terminal and shells/applications that are running. Much like how color, cursor positioning, entering/exiting raw mode etc are already done. Though I think some tight specialized integration might be a good start to explore these ideas before the protocols are formed.