The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
replyExhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise.
replyXSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.
The problem here is runtime includes, especially the "drop source in place" style includes, coupled with dynamic dispatch at runtime. These two things in combination make static analysis of execution flow anywhere from really hard to impossible
replyI get it, but it's hard to track
replyIf by "hard to track" you mean not knowing what template is producing an observed bad output, the modularity of self-contained templates and XPath expression is likely to help with debugging.
reply