Okay, the answer is simple and somewhat disturbing: the new parser just failed to parse the filter in question with the syntax error, so it presumably never got executed. I've expected this to fail more loudly than silently failing open, but I am not sure how the filter edit hooks actually handle this.

So, my current understanding is that the reason why we are hitting this is
(1) There is no recursion limit in the new parser (definitely a bug),
(2) Previously the tree for same operations were flat, meaning that the trees we now get are much deeper. I'd need to think how to work this fact around.

The specific change which happened, as far as I understand it, is that the precedence remained the same, but apparently the new parser treats boolean operators as right-associative, whereas it used to treat them as left-associative. This is an oversight on my part. I will write a patch to fix that and add tests.

What I meant is the traditional power structure of Wikimedia projects ask bureaucrats are the ones to grant sensible rights. Independantly with their sysop status, they are also used to grant sensible rights,

In T144599#2607180, @MarcoAurelio wrote:

No, they're not different. They all have the same purpose: unbundling from
the sysops the privs to edit css and js site files and other things. That
the permissions are a bit different across the sites is nothing new and it
happens with some non standard groups such as patrollers, rollbackers, etc.

So, there seems to be a security concern expressed here about allowing sysops to delegate editinterface permission. However, the more I think about it, the more unconvinced I become that there is any actual difference between the existing situation and the proposed one. Could someone elaborate what the suggested threat model is?

Well, I clearly cannot reproduce it locally then. Unassigning myself from this.

Will take a look.

I am fairly skeptical about the requested change. The situation for as long as I remember have been (and correct me if that changed) has been that the account usurpation policy is up to each individual project, and some projects never allowed usurpation under any circumstances. I am concerned that we might be possibly circumventing local policies with this decision.

So, do I actually have to go and reimplement adminstats? I would be happy to do that, but I never wanted to duplicate effort.