Earlier quoted context omitted.
Then XSS attacks would insert before =) What we need is literal separation of control statements (eg, ) from content such that neither can be easily misinterpreted, but that would be a significant departure from existing design.
That shouldn't work for the same reason that you can't escape a bound SQL query parameter in a pre-parsed query.
A modernized, preferably static version of perl's taint mode might work. You need two types of strings, one for trusted and one for untrusted strings, all your output functions accept only trusted strings, all your input or request parsng function return untrusted strings, and all naive string manipulation functions return untrusted strings if at least one of their arguments are untrusted. Then the possibly vulnerabe code is limited to a few statically identifiable routines that take untrusted strings and return trusted ones. They still may be buggy, but at least you know which parts of your code may induce vulnerabilities and need special attention.
And with modern type systems, these types might even be phantom types incurring no runtime overhead. Athough things like the differences between "safe for passing to a browser" and "safe for passing to my SQL-server" might compliate the architecture.