[saagarjha]

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.

[tialaramex]

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.