AJ this is a great idea and we will likely implement it. But every time someone suggests a feature that sounds like a great idea, we have to think about how that may affect other users in a negative way. We could improve John's workflow and break Sue's.
I realized that I sometimes myself have created codes that include a pipe symbol '|'. I do this when I want to have a code that is based on more than one variable. For example, lets say you want to have a code based on {model}, but there are two photographers (or more) using the same camera model. So you can make a code that is more specific that combines their initials with model, and for editor sanity I use the pipe symbol.
={model}|{fbas:0,3}=
This assumes the photographer shoots in sRGB not AdobeRGB.
Then codes could be like:
D900|DJW
(assuming you have more than one photographer with a hypothetical D900 camera that didn't have a serial number in Exif)
So by adding this feature, it would not be "backward compatible" for anyone (besides me?) with a code replacement file as above.
So..., maybe a more obnoxious character such as '&'? But even this could break if someone uses an IPTC field as a code and the value of this IPTC field contains that character. A contrived example:
={event}=
and this evaluates to "Sue&John" because that's how the photographer notates her wedding events (because she is organized).
So ={event}= would look for codes "Sue" and "John" but they don't exist. The code is "Sue&John".
This is why I don't recommend mathematicians using PM to write their formulas since they may involve something like an '=' character.
--dennis