I don't understand your claim that strong interpolation is wrong and the source of injection attacks, which are well known where building strings is much harder than interpolation. They come from not validating input data before use; requiring lots of work to build strings doesn't make it any more likely that people will do it safely.
"They come from not validating input data before use;"
I say they come from building APIs that don't require a statement of the correct way to escape output. Of course if your API doesn't require it, it doesn't happen.
Even the way you phrase it is dangerously wrong... validation of input and escaping of output are two entirely different things. I've implied this in my phrasing but let me spell it out, validation happens on the way in and is related to your local semantic domain (business rules, legal values of "an IP address" or "an email", etc), and escaping happens on the way out and is performed by the string "interpolation" or template system. If you've got them munged in your head into one concept, you're probably not writing correct code.
(For what it's worth, I see this formulation of the "root problem" more often than I see the right one. I really ought to write this up as a blog post.)
I'm looking out on the world and seeing what is there, which is a steaming mass of code that incorrectly manages strings. The fact that it is theoretically possible to correctly manage them is not that interesting of a fact, because observationally, it doesn't happen.
> Even the way you phrase it is dangerously wrong... validation of input and escaping of output are two entirely different things.
Yes, they are, but preventing injection attacks is the domain of the former more than the latter, and your suggestion that it is the other way is dangerously wrong. There are security risks addressed by the latter, but if you are relying on it to prevent injection attacks in the usual case [1], it means you are allowing untrusted unvalidated external data into your system and doing general processing on it and just trying to avoid a problem on output.
You prevent injection attacks by preventing malformed data from being injected into the system (at least, from such data making it past a validation component), not by allowing it freely into the system and trying to mitigate certain of its harms by escaping output.
Its true that proper escaping may help to limit injection attacks where imperfect validation has failed to prevent bad data from being accepted and processed, but even there more complicated APIs for string building don't make it more likely that people will do it right.
[1] the one place where it may be a proper mechanism for addressing injection attacks is when you are reporting the rejection of malformed input data, in which case you may have a legitimate need to use (some part of) the malformed data in the error report.
