Focusing back on the main discussion about bringing c-style formatted strings to the language then, as I said before, this is perfectly feasible at the point the new parser kicks in and people need to translate their scripts to take advantage of it. The translater will be able to handle rewriting the string literals appropriately. An important thing to remember here is that we are just talking about the interpretation of the tokens in the script - the act of consuming the string literal at the lexical analysis phase will result in a value that has the appropriate content (i.e. escapes resolved) and as such causes no performance impact.
Maybe I missed something in these (to date) seven pages of posts... you're suggesting that it will be necessary to run existing scripts through a translator to bring them up to conformance with the new parser? I like this idea, even with the pain that forced translation would bring. That being the case...
There are two issues here: readability and compatibility.
The two approaches that I prefer, agnostic quotes and c-style character escaping, both fail the backward-compatibility test separately or together if no translation of current scripts is involved. But taken together I think they improve readability.
The forced use of the "format" command is backward-compatible with current syntax but at a loss of readability.
Same with the "@" syntax, which has, I think, the added drawback of repurposing an existing operator.
Is there a way to mark scripts as having been translated, i.e., set a custom property or something that says "this script was made using a previous version of the engine and has now been updated for the new string syntax"? If so, then the translation could be automatic and behind the scenes.