Boiling the ocean.

Right now, for instance, it requires two processes to even work: a server and a viewer. That's pretty insane.

Really, all this system actually needs to work is a way to communicate some meta-data about the streams. You can then write a nice GUI shell (WebKit or not) that can use that meta-data, a nice TTY that uses it, or even just run plain ol' Bash and stock UNIX tools and let them ignore the extra meta-data.

You could do this with a relatively simple UNIX-y protocol. Set a couple environment variables and open a fourth bi-directional socket for meta-data communication. Something like SHELL_METADATA_PID which serves the purpose of indicating that the metadata socket exists and making sure that only the target process tries to read/write to it (and not sub-processes, which would have a different PID). Tools that support the new metadata and which see that the env var is set and the right PID can read RFC2822 style meta data from socket 3 and write output metadata to socket 3. The main shell is responsible for creating these sockets and sanitizing inputs/outputs between pipeline stages. If the shell is just Bash or something, the env var is not set (or even if it was set by the parent of Bash, it would never match any of the children, so they act as if it was unset) and so those new tools just assume their input is untyped data and don't bother writing out any extra metadata. Wrap up the basic code for that in a small library and then write a shell that can use the extra metadata for final output streams and there you go.

A more complex -- but more powerful -- protocol could also be devised that allows things like negotiation between stages. Maybe ls can output some nice structured format, but if the next process in the pipeline doesn't want to deal with that or doesn't know how, it should get the classical text output of ps. That requires that either ps knows what output is desired, or requires the shell to transparently translate the rich output into the classical output between the pipeline stages. Either of these approaches require some way to get the accepted inputs of subsequent pipeline stages, and the shell-based translation additionally means that an enchanced ps would only be able to work with classical tools while running in an enhanced shell (so I'd suggest making the output format selection ps's job). This is a tougher problem to solve, but it's still worth it.