Fact: Saxon’s API is very impractical, not made for expression transformation or even inspection at all. Given how deep we’d have to delve to get anything working, it’s likely that version updates would break everything anyway.

We could maintain our own XPath parser. This would abstract us from Saxon/Jaxen and individual versions thereof, and allow us to identify more optimisation opportunities. Given an AST, we can perform optimising transformations, and identify rulechain visits, then dump it to an XPath expression string and let Saxon parse it to its own representation. This parser could also be used in the designer, as suggested in #1192

Interesting things that could be done with that:

• Prune alternation branches that are conditioned by a rule property. E.g: //N[$reportNs=true()] | //M[$reportMs=true()]. The value of the property never changes at run time, which Saxon can’t know (we use a dynamic context). But if e.g. $reportMs is set to false, then the M branch can be safely discarded, and only one rulechain visit would be added.
• Identify more rulechain conversion opportunities (eg //A/(B | C)/X -> //A/B/X | //A/C/X, which is currently ignored by Jaxen IIRC)
• Identify PMD function calls, to determine framework dependencies of the rule automatically (refs [core] Use annotations to resolve rule dependencies to frameworks #437)
• Add our own compatibility layer to port old Jaxen rules to Saxon, for example to address [core] Inconsistent boolean value representation with Jaxen #1244
• Identify deprecated/ inexistent attribute usage statically, before rule execution, instead of inspecting attributes at runtime
• Identify and report inexistent node names

Things to care about:

• Avoid doing that analysis several times for the same query. Currently, preliminary transformations are done during rule initialisation, which means they're done k times if we have k threads (right?).