I believe a number of the new xs:error tests are returning XPTY0004 when FORG0001 would be more appropriate. However, the rules are not completely clear, so I'm raising this as a spec bug.

The rules that apply are in F+O 18.3.5. This states that the supplied value must be either a string, or an instance of a member type of the union, or castable to a member type of the union. If it is a string, as in test xs-error-010, then it seems clear that the appropriate error is FORG0001 (the test is written to expect XPTY0004). If it is any type other than string, then none of the three conditions applies, and the spec isn't clear what the error code should be; one could argue for XPTY0004 in this case, by analogy with the rule for casting to atomic types ("If casting is attempted from an ST to a TT for which casting is not supported, as defined in the table below, a type error is raised [err:XPTY0004]XP30." in 18.1)

However, this is a little problematic with regard to the third rule. ("A value that is castable to one or more of the atomic types in the transitive membership of the union type (in the sense that the castable as operator returns true)."). This rule depends on the source value, not only on its type, so a type error seems inappropriate.

It seems unreasonable to require implementations to distinguish the case where no instance of the type of the supplied value could be cast to the union type from the case where the particular instance cannot be cast to the union type, solely in order to raise different error codes for the two cases. Therefore I propose that any failure to cast to a union type (because none of the three rules is satisfied) should result in FORG0001.