Sure, that is a progress bar. And it's something countless devs have wasted hundreds of man-years reimplementing over and over again, instead of delegating to the terminal application. Because we're stuck with handling transparent character sequences.

This makes no sense to me.

There is only one terminal that user is going to use, and as an app author, you cannot choose which one is it. There is a good chance that your app will run in terminal which was last updated many years ago, and you cannot do anything about it.

On the other hand, you can link to any library you want, and as an app author, you have full (or almost full) control over it. There is a good chance your app will use the libraries you want (especially if its in modern language), and in the worst case you can vendor library locally.

It follows that we should have as much functionality as possible in libraries, and as little as possible in terminals. Your progress bar? Should be a library. If there is a terminal support for it, it should be an optional low-level "eye candy" (some might even call it "bloat"), with all the real logic (like ETA estimation, rate limiting, and formatting) implemented in libraries.

This applies to all your other ideas, too.

"proper inter-process message passing via standardised interfaces" - that exists, and has nothing to do with terminals. Depending on exact details, it is called JSON, DBUS, XML, etc... If you want Powershell-like "ls | select .name", then you don't need to mess with terminal either - it's all shell functionality (maybe with some env var conventions).

Terminals already offer completion like IDEs do, try hitting TAB. I agree it might be nice to use a different font for those, but there is no need for redesign, you only need a new escape sequence like "start/stop floating window" (but again, some might call this "bloat")