> assuming an html() function would interpret plain Templates as HTML

Agreed; it feels natural to accept plain templates (and simple sequences of plain templates) as HTML; this is hinted at in the PEP.

> html(t"<ul>{map(lambda i: t"<li>{i}</li>", items)}</ul>")

Perhaps more idiomatically: html(t"<ul>{(t"<li>{i}</li>" for i in items)}</ul>")

> syntax highlighting and type-checking are keyed off the fact that a template can only ever have a single tag

Yes, this is a key difference and something we agonized a bit over as the PEP came together. In the (very) long term, I'm hopeful that we see type annotations used to indicate the expected string content type. In the nearer term, I think a certain amount of "clever kludginess" will be necessary in tools like (say) black if they wish to provide specialized formatting for common types.

> a special html() processing instruction could both emit server-rendered HTML and say, lit-html JavaScript templates that could be used to update the DOM client-side with new data

I'd love to see this and it's exactly the sort of thing I'm hoping emerges from PEP 750 over time. Please do reach out if you'd like to talk it over!

Python already has built-in data structure literals that allow you to express lispy DSLs:

    html(['ul', {'class': 'foo'}, *(['li', item] for item in items)])

The benefit of lisp-like representation is you have the entire structure of the data, not just a sequence of already-serialized and not-yet-serialized pieces.