So if the compiler is only doing stupid-simple scanning of the replacement-field, looking for a delimiter, it would have to keep track of double-quote pairs too, and that means it has to handle more escape sequences, etc. (it may well have to anyway, depending on how the WG decides to specify the processing logic, but I was trying to keep it very dumb/lazy parsing)
That same scanning is what a brain needs to do. So, definitely, it needs to be KISSed into not needing a second look. An "introducer-parameters" replacement field would have been easier to deal with, since its "found introducer, now match what follows against a simple pattern until some space". I'm not sure how the double-quotes would be an issue, but it sounds like you're trying to just copy Python.
But anyway, I thought it would be better to try to keep to the existing C++ format-string syntax as much as possible. I think that's what users would expect?
Sure, I suppose now that the paint has finished drying. I've gotten used to whatever is already in-place, which really means anything now.
What I would like out of something like this: No new framework or runtime coupling. No new syntax that performs allocations. Just syntax-only WYSIWYG, and the translation of WYS to WYG is just an exercise in rearranging symbols. I was thinking of something along the lines of infixes between literal fragments, since this would work well with a simple preprocessor (token-pasting aside). OTOH, large applications that handle text for presentation with format strings do so parametrically, (format strings with numbered arguments in different places depending on locale) so this would be more of a thing for small project readability.
It also helps if it doesn't look itself like a regular expression. Not that the status-quo has this problem per-se, they still don't read well with find & replace (each "{" has to be escaped, but who uses regex anyway?).