Overall this seems like a reasonable compromise when it's not clear how quick the move to XPath 2.0 is likely to be.

However, I worry a bit about: If authors don't say, then they get what the implementor decides. True, it'll usually work out fine, as you say, but maybe sometimes it won't in surprising ways. It would have been better controlled to say it's XPath 1.0 unless the pipeline author says otherwise. That way the default would only break with a 2.0 implementation which doesn't do backward-compatibility mode. For many simple XPaths it might be sensible to allow the author to explicitly say that 1.0 and 2.0 are both OK.

As long as the xslt component leaves it up to the implementation whether or not to use an xsl/xpath 2 engine, I think it's very reasonable to limit xpath expressions in xproc to version 1.0.

Thus if you really, really needed something from xpath 2 you could do a transform in the xslt component and have it come up with a some sort of the routing meta-document that you could use an input to other pipelines. I think that this is a descent design pattern anyway because if you need xpath 2 you're probably doing something complex and encapsulating the complexity outside of the xproc flow makes sense.

Futhermore, I think that the implementation support simply isn't there yet. Of (what I think are) the big four xsl engines:saxon, msxml, libxml and xalan; only saxon is at the 2.0 level. I think the msxml team has started on it, xalan is still thinking about it, and I haven't heard/seen anything from the libxml camp.

Therefore, I agree that it would be wise to keep it simple and require only xpath 1.0.