I expect that removing the need to know about attributes (via the other RFC) will definitely introduce some opportunities for simplification, but nothing huge – the overall structure will remain similar.
I’ve also been considering whether this could be pluggable – if the interface is simple enough, people could provide their own content-validation implementations in cases where the default isn’t powerful enough. I could probably define a smaller minimal interface that an implementation has to implement, but some of the extra methods provide useful optimizations (for example, to get a match after a known-to-match fragment, if the content expression has only one state, we don’t have to play through it, we can just immediately return that state).
Something like the current ContentMatch class – a value encapsulating a match state – probably remains necessary. The interface you propose doesn’t really express what needs to be expressed – adding a node to match creates a new match state (or a failure to match), rather than a boolean, and filling works in terms of fragments, not positions in a document.