devtrackers.gg
The precedent is that not/never overrides (e.g. RT > always crit). I think they did make an exception to this recently, though.
The precedent is that not/never overrides (e.g. RT > always crit)
It's this, but annoyingly that's different than it seems in this case, because the syntactic sugar of the fancy descriptions that are used reverses the positive/negative value of the statements. What's actually happening isn't "X damage bypasses/does not bypass ES", it's more like "ES can/cannot intercept X damage".
So effects that make damage bypass ES are the "cannot" case (ES can't intercept that damage and protect you from it) and take precidence over the "can" cas (ES can intercept that damage before it hits life).
So under the hood, the exception to the rule is actually that the implicit standard state of ES not being able to protect against chaos damage gets overridden by the "does not bypass" modifier which says it can. This can be explained away either as "actually stated modifiers take precidence over standard behaviour that doesn't come from a modifier", or by treating the implicit behaviour as "ES doesn't intercept chaos" rather than that it "can't". Neither is 100% convincing, but that's how it has to work anyway.
So actual modifiers that say ES won't stop a certain damage type (such as this keystone) will take precidence over those that say it can stop them (such as Shavs/Solaris Lorica), which in turn take precidence over the default behaviour where it doesn't against chaos but does against other types.