Personally, I'm a bit mixed on the wisdom of changing the interpretation
of escapes in sieve scripts, mainly because the original spec defined
the meaning of _all_ escapes instead of only defining those that were
required ( \\ and \" ) while leaving other escapes as having undefined
behavior. An implementation that complies with RFC 3028 cannot
simultaneously comply with a specification that requires \0 to be
treated as a NUL or \u0025 to be treated as a percent sign.
If the WG decides that breaking backwards compability on this point is
worthwhile, then I would suggest we go ahead and explicitly warn script
authors that future extensions or revisions MAY redefine other
backslash-character combinations and that scripts should therefore avoid
extraneous backslash escapes.
Also, please note that currently, backslashes are only special in quoted
strings and not in multi-line strings. That leaves a choice of either
a) making quoted strings strictly more 'powerful' that multi-line
strings, or
b) changing the interpretation of backslashes in multi-line strings.
Personally, I find (b) a non-starter.
Regarding the discussion around how to express NUL, I would rather
_only_ have \u and \U, so that NUL would be \u0000 (or \U00000000). I
dislike escape sequences that are neither fixed length (like \u and \U)
nor bracketed (like perl5's \P{name}).
Philip Guenther