For ports that have maintainers that have Phabricator accounts, its nice to add them to Reviewers: even if an existing PR exists and even in the case of an implicit/blanket/other approval, as a heads up

Anything that isn't a version update (unless its a security, bug fix release version update), is a MFH candidate. More precisely, there ought to be a reason (by policy or otherwise) not to MFH something, and in particular, merging things makes future merges easier (as one has to either commit all intervening commits anyway, or do direct to quarterly merges, which can be risky

Is there a present or future (upcoming base change for example) impact of not removing the redundant escape? If so, clarify that in commit message

make escape of most ordinary characters an error appears to get at the impact, but it wasn't entirely clear, at least to me, whether its theoretical, or whether leaving the escape in place would return an error if not removed, after the relevant base change was commited

In D23698#521114, @koobs wrote:

Is there a present or future (upcoming base change for example) impact of not removing the redundant escape? If so, clarify that in commit message

make escape of most ordinary characters an error appears to get at the impact, but it wasn't entirely clear, at least to me, whether its theoretical, or whether leaving the escape in place would return an error if not removed, after the relevant base change was commited

Indeed- the implied part of these changes is that they're being made specifically because they are erroneous. I could make others on the basis of correctness, but have opted not to do so for now.

I'm with @koobs on an "informative" error returned on this. If it's possible.
I think it might lend itself to *Maintainers* providing a cure. :)
Thanks for all the time, and effort put into this!