Saxon

Ignore the bit about 10.3 - further testing leads me to believe that this is a separate issue.

I see the error reported in 10.3 as

Type error at char 58 in expression in xsl:variable/@select on line 25 column 110 of bug-report.xsl:
  XPTY0004  The items on the LHS of the '?' operator must be maps or arrays; but value (110)
  was supplied

I think it's perhaps unfortunate that the specification allows predicates to be reordered; it's certainly a reasonable user expectation that the first predicate can be used as a "guard" for the second in this way. But the language spec is explicit that it is allowed: see §2.3.4:

The expression in the following example cannot raise a casting error if it is evaluated exactly as written (i.e., left to right). Since neither predicate depends on the context position, an implementation might choose to reorder the predicates to achieve better performance (for example, by taking advantage of an index). This reordering could cause the expression to raise an error.

$N[@x castable as xs:date][xs:date(@x) gt xs:date("2000-01-01")]

To avoid unexpected errors caused by expression rewrite, tests that are designed to prevent dynamic errors should be expressed using conditional expressions. For example, the above expression can be written as follows:

$N[if (@x castable as xs:date) then xs:date(@x) gt xs:date("2000-01-01") else false()]

Saxon has an experimental extension to help with this use case: in the expression A andThen B, it's guaranteed that B won't be evaluated unless A is true.