I guess because of:

If ordinal numbering is not supported for the combination of the format token, the language, and the string appearing in parentheses, the request is ignored and cardinal numbers are generated instead.

Like many aspects of the format-X functions, implementations have a lot of latitude. We can either make the test results strictly reflect this, or we can make best guesses as to consensus interpretations of the spec. For example, we could allow b or b'th.

We generated the result

bst

(i.e. 1st, where 1 == b)

I'm happy to change our implementation, but I'd like some rules to guide me on what changes to make for compatibility with other implementations.

The aim is to be user-friendly, and to me bst doesn't seem to achieve that. I can conceive of someone wanting the sequence

Ith Jth Kth Lth Mth Nth

but it's a bit far-fetched, and you would probably want the 'th' to be a subscript in which case you would add it outside the scope of format-integer.

So as far as the test is concerned, I think the principle should be that if there's evidence of a "real-world" usage of an ordinal equivalent of the sequence a, b, c, then we should make it an acceptable result, but to my mind "bst" doesn't satisfy that criterion.

Probably "b" as a starting point for a sequence is a bit outlandish anyway. I added support in Saxon for any alphabetic start point so you could do (i, j ,k) or (x, y, z) or (p, q, r), all of which are encountered as sequences in real life. But there's nothing in the spec to create an expectation that these sequences will be supported.

This test was written to check the parsing of format pictures. It seems clear that the picture is valid, but the result is implementation-defined. I'm therefore going to change the assertion to

<assert-type>xs:string</assert-type>

to make it clear that any result other than an error is acceptable.

Confirmed fixed.