It has fundamental conceptional flaws. But hell, finally someone is rethinking the terminal, please continue working on this!
Here's the direction I would propose:
It must be 100% backwards compatible. This is not optional, anything else is a non-starter. Likewise trying to re-invent the entire unix userspace toolchain is a terrible idea.
So why not do it the UNIX-way and how terminals have always done it:
Start by emulating a normal terminal (xterm/vt10x). Add support for a special ESC-sequence that switches the terminal into TermKit mode (and another one to switch back).
This way we have a normal terminal, with a bonus-mode.
A simple cli-wrapper could be provided to mix the "magic" in. E.g. to cat a PNG I would: 'cat foo.png | tk_wrap'.
And on the screen that image would magically be embedded below my command line, just like any text output would.
tk_wrap would be small wrapper that first emits the termkit-esc, then the stdin-data (converted to the json meta-format), and finally the termkit-end-esc.
That's the basic architecture that I'd like to see. And from there, sky's the limit.
To me, it's like suggesting that the iPhone would be better if you added a physical slide out keyboard to make it more old-school; sure, you could do that, and would probably score popularity points with unconvinced customers.
But you would compromise tons of secondary aspects of the device to do so.
If TermKit would have a "traditional" mode of operation, and let you switch back to it, it would mean that TermKit has failed in being a comprehensive tool. I hope I can get around that.
As TK is essentially an _improved terminal_, I don't see a reason to totally break off from the current power of the traditional CLI, especially if alienating current power users in the process.
The biggest limitation are the existing applications. Initially the new features could be opt-in, and as the new idea picks up, you would then have more and more console applications support the new type of terminal.
While I can understand your viewpoint I'm worried that it will prove difficult to gain mindshare by attempting to replace existing terminals instead of augmenting them. As long as I can't use TermKit as my only terminal my motivation to even try it is non-existant. And I'm sure most people are like me in that regard.
Either way, I hope you will keep on working on it, as I'd love to see terminals become smarter. Once it's fit to fully replace my iTerm I will give it a shot.
As it should. Unix disdains comprehensive tools in favor of the pipeline and, generally, picking the right tool for the job.