Displaying multiple simultaneous jobs is a rather different process than running multiple simultaneous jobs. Maybe it should be seperate. Either way though it's probably best left 'till last. Hmm. You use 3/4 of the same machinery either way though. And as mentioned, a terminal may not even be necessary. As in, no data dependencies or fixed order of operations? You'd need explicit means of synchronization, then. Not just critical sections, but means to tell when a section of code has completed to put inside the critical sections. That could solve a whole lot of problems if you could do it. But you can't avoid creating processes for external commands. It'd also mean you'd lose all the easy ways to scope files and variables, you'd have to have to manage them all brute-force instead of operating with the kernel's support.

I just realized another big problem with running external programs in a threaded shell. fork()ing clones all your threads! You need a mutex or semaphore you can stop all your threads with so you can stop the universe, fork(), redirect and exec in the child, then resume. Or a seperate process you feed commands into with a pipe that creates children for you -- might actually be more efficient than forcing all your threads to run in lockstep.
AFAIK there's not a bunch of different wgets out there, it's all the GNU wget. They might be compiled with different options -- Windows versions might lack SSL and always print dots -- but they're still the same source code. You can verify that it's printing dots one-at-a-time with strace:

Code:

$ strace wget http://website/ -O /dev/null > wget.log 2>wget.err 
$ grep "write(2" wget.err | tail
write(2, ".", 1.)                        = 1
write(2, ".", 1.)                        = 1
write(2, ".", 1.)                        = 1
write(2, " ", 1 )                        = 1
write(2, ".", 1.)                        = 1
write(2, ".", 1.)                        = 1
write(2, ".", 1.)                        = 1
write(2, ".", 1.)                        = 1
write(2, ".", 1.)                        = 1
write(2, ".", 1.)                        = 1
$

Something else is doing line-buffering for you, maybe the application you're watching the file with, or maybe a pipe.

So there's only two cases, terminal vs non-terminal, not three, terminal vs pipe vs file. Whew. Naturally. I'm not sure it's the shell's job to fix this, though. Anyway it's probably not worth worrying about at this point, when there's not even an implementation of the basic no-frills algorithm. That's not the shell's fault and not the shell's problem, though. If you discovered something with even uglier output, would you add more special modes to accommodate it?

Taking over the terminal that way also means there's no longer one place to type input and one place to read output. That's fine in screen when you created the windows and know what they are, but when they create and destroy themselves in droves, the interface might seem just as bad a scramble as you were trying to fix.

Terminal-using programs like login systems might also end up printing normal prompts in bizarre places because your terminal isn't working the usual way -- or you could not give everything a terminal unless asked for explicitly, in which case they'd just fail to work at all... Or you could give each and every external command its own little shell window on the off-chance that it might need it.

I suppose you could reserve the lower half of the screen for normal console-like I/O but you'd have to emulate it with a pty, which'd turn your shell into a hacking tool -- people could spoof password logins by default. And your shell would look more like an IDE than a terminal.

Not that it wouldn't be useful but maybe these things really do deserve to be separate. It should be kept out of the way and only used where you tell it to explicitly, like a debugging feature, and even then, only when a terminal's available, and with the debug window things output-only.

Another tidbit that could help simplify this a lot is how some terminals can set a scrolling region. It's like a window you can create inside the terminal itself just by printing certain escape sequences. You could set aside the upper half of the screen for some shell window things and use the lower half as a real terminal for things like ssh and passwd to pop up password prompts in.

Of course, only some terminals support this, so it's not portable. You'd also have to carefully time what things get written when.

Bottom line is that taking over the terminal like this means all the usual terminal behavior you take for granted and depend on can't be depended on unless you do it all yourself. Funny you should say that, there's actually something on my system that does log wget's dot-lines. Whether it's useful is a matter of taste anyway. It does tell you more information than a single line of progress bar -- it tells you transfer rates over time, not just the average speed. Again remember that you're writing a programming language, not a GUI. People might put it to uses you don't expect, or might not be able to because you didn't give them means to do what they "usually" don't need to. Holding too strictly to things which prettify the terminal could make your language hard to use without one. There's a lot of different ways programs could print output. Do you want to add special modes for all of them, or just give the programmer a way to get at what's there?