No matter how many new languages we invent, this problem of surprise sub-languages being parsed from strings never goes away. It's almost as if program code should be somehow impossible to confuse with user-visible text. Maybe there's no good solution though :(
The appropriate constraint is well known and exists in several languages. The magic format strings mustn't be variables. In Swift there's a type StaticString which matches literals like "This is some text" but is not used for any interpolated strings, or other arbitrary variable values.
Of course just because the constraint is known doesn't mean (as you illustrate) that everybody knows about it or makes use of it in their own programming.
This isn't an "appropriate constraint", because dynamically constructing format strings is a thing that normal programs can and do do. StaticString exists due to various limitations on the os_log APIs and it's somewhat amusing that you're trying to spin it into some sort of "known" fact that everyone should follow.
In almost all cases this feature is a foot gun, reminiscent of eval() and similar cases and so should not be provided. Sure, it's easy and flexible, but in exchange it's horribly unsafe.
Imagine that, expecting a RESTful API for some new remote service you're accessing you discover it instead offers precise instructions for where the Javascript buttons are rendered on a 640x480 Internet Explorer 6 browser, instructing you to automate pressing the buttons through a browser automation gadget.
You'd be aghast right? Sure this would work but it's clearly not an ergonomic way to provide automation, why not just offer a RESTful API like most similar sites?
Dynamically constructing format strings is the same ergonomic awkwardness, for the benefit of lazy workers who couldn't be bothered to actually deliver what was needed.
Instead I want a way to reach into the same formatting infrastructure that is used for my string literal formats, and manipulate it dynamically, not by creating "format strings" dynamically.
As an example, if your formatting library can format("{some}{values}{with:parameters}", v1, v2, v3) I ought to be able to write my own different function myfn("[different][syntax][same#features]", v1, v2, v3) re-using the infrastructure from the existing formatting library, rather than needing to write a function myfn("[different][syntax][same#features]") which has a result "{some}{values}{with:parameters}" in order to deliver the same effect but via this sub-language.
