To clarify somewhat: html is a presentation language.
That's not appropriate for either control or data planes by default.
example-
let's define the data plane as an associated list of byte-strings of u8 characters. This covers current common unix pipe usage on the terminal. If we include some lisp syntax for routing & choose to complect some control and data on the command line we then can compose:
But, fundamentally, the control plane needs to be asynchronous, so there needs to be a signal handler that a program can listen on that takes a stream of associated-lists with the rough form of:
the program listening needs to be able to register with its parent process that it gets a key stream.
anyway. we can work out this system in some level of detail with different representations. The key point is that this needs to be just data addressable easily, without significant difficulty parsing. It also needs to be lossless by default and not dependent upon hacks like timeouts as part of its interface to its consumers. (n.b., it should allow adding as many bucky bits as a keyboard developer wants).
now, if the terminal wants to formally specify as its interface that it takes all output streams keyed by "html-presentation" and render them as html, that seems like a very featureful possibility. I would not write that, but I could see others doing so.
I think it would be extremely useful and valuable to start on such a project, but I'm not sure how much interest such a thing would have.
I certainly don't agree that Emacs Lisp is the appropriate development engine.