The number CIRCLED DIGIT ZERO is not consecutively before the CIRCLED DIGIT ONE in the Unicode codepoints. I.e., ZERO is at U+24EA and ONE is at U+2460.

However, the Unicode spec makes clear that these are part of a range. I think therefor that the test output is in order if "0" is replaced with U+24EA, but would like to hear the WG consensus of this.

The XSLT 3.0 spec for xsl:number in 12.3 says

For example, the formatting token ① (circled digit one) has a range of 1 to 20 imposed by the Unicode character repertoire. 

But F+O 3.0 for format-integer has correctly updated this to:

For example, the format token ① (circled digit one, ①) has a range imposed by the Unicode character repertoire — 1 to 20 in Unicode versions prior to 4.0, increased in subsequent versions.

In both cases it's only an example, therefore non-normative, but we should fix the XSLT version of the text, and recognize that Unicode now has a circled zero, which should probably be used in this test.

I have modified the XSLT 3.0 text to match the F+O text as suggested.

Tim Mills wrote:
> expected result starts with 0 (&#x30), not a circled zero (&#x2460).

Michael Kay wrote:
> For example, the format token ① (circled digit one, ①) has a range 
> imposed by the Unicode character repertoire — 1 to 20 in Unicode versions 
> prior to 4.0, increased in subsequent versions.

However, CIRCLED DIGIT ONE is U+2460, ZERO is U+24EA. They are not consecutive. Both have been around since Unicode 1.1. 

Are we suggesting here that the outcome from a processor should (optionally?) be:

<out> 0 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ 21 22 23 24 25</out>

Or:
<out> ⓪ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ 21 22 23 24 25</out>

Or even: 
<out> ⓪ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ ㉑ ㉒ ㉓ ㉔ ㉕</out>

Numbers up to 50 have been supported since Unicode 3.3.

These ranges are not consecutive:
0:     24EA          (since 1.1, 1993)
1-20:  2460 - 2473   (since 1.1, 1993)
21-35: 3251 - 325F   (since 3.2, 2002)
36-50: 32B1 - 32BF   (since 3.2, 2002)

So for these Unicode ranges in particular, it is incorrect that only 1 to 20 existed in Unicode prior to 4.0. All these circled digits where added earlier.

This means that the sentence in the XSLT 3.0 spec is possibly incomplete: "For example, the formatting token &#x2460; (circled digit one) has a range of 1 to 20 imposed by the Unicode character repertoire."

I am not sure how to move forward. Since these ranges fall under implementation-defined behavior (and add to that the supported Unicode version is implementation-defined as well), I don't think there's anything we can force here, so I propose that the result of the test should iterate these alternatives.

I've moved forward and implemented a solution, essentially:

* added new dependency enum values for numeric formatting
* added range dependency to indicate supported ranges
* fixed the test by allowing alternate outcomes
* fixed the test by adding (new) dependencies

In addition, I added a bunch of tests for other No category numbers that have a more or less natural formatting range implied by the Unicode spec.