I wonder how string interpolation interacts with translation though? I thought the whole idea of the numbered placeholders was so that you could translate the string and rearrange them for different languages. Now do your translators have to be careful not to break your code if they're editing it as part of the string?

Even if an application gets localised, it may do less formatting of localised messages than of non localised ones (think (debug) logging, textual protocol formatting, exception messages and the like)

I also expect that a large fraction of applications never gets localised (in-house tools, scientific software, etc).

In total, I think there are orders of magnitude more lines of message formatting code that do not get translated and likely never will be translated.

It appears modern language designers think it worthwhile to make life for that use case a bit easier.

(it is not that the code gets much shorter, but more that, for true translation, you have to move the format string into a resource, and load it from your code)

That's a good point. I imagine it will require consideration by the developer/architect of how to handle internationalization. It may be that you don't want to use string-interpolation for any strings that require translation.

.NET has a higher level built-in mechanism for dealing with translated content (Resource files). I don't think this new language feature is intended to replace that.