A really good example here is the p"C:\" question. Is the proposal that the "string part" of the literal is just a normal string? If so, then how do you address this genuine issue that not all paths are valid? What about backslash-escapes (p"C:\temp")? Is the string a raw string or not? If the proposal is that the path-literal code can define how the string is parsed, then how does that work?
I don't usually work with windows, but I can see how this could be a pain point for windows users. They need both backslashes and the quotation marks in their paths. As nobody has suggested yet how to deal with the problem, I'd like to give it a try. Behold: p{C:\} The part within the curly braces is considered a "really-raw" string. The "really-raw" means that every character is interpreted exactly as it looks, there are no escape characters. Internal braces will be allowed too, provided that they are properly nested: p{C:\"Program Files"\{hello}\} If you **need** to have unmatched braces in the string, your last hope is the triple-braced literal: p{{{Letter Ж looks like }|{... }}} The curly braces can only be used with a string prefix (or suffix?). And while we're at it, why not allow chained literals: re{(\w+)}{"\1"} frac{1}{17}