We currently allow overriding a variable if their types, implicitly or explicitly, are identical. 

I think that if we default it to item()*, this can be problematic for implicit defaults like document() or xs:string. In your example it is statically known that the type of the second $x is document() and the type of the first $x is xs:integer.

However, the static type may not be definitively known. The select-expression could call fn:collection, which can return any type and I'm sure there are other possibilities. Though statically, these would simply default to item()*.

I'm not sure what the best cause of action is. One alternative way of reading "the declared types must be identical" is that it seems to implicitly require a declared type on variables. In the absence thereof (i.e., no as-clause), you cannot override the xsl:variable. The logic being: "when the type is not declared, its type is unknown and cannot always be assessed statically to be equal".

Hmm, one complicating factor is that the large example on binding components (3.5.3.5 Binding References to Components) exclusively uses variables that have no as-clause. Having that example suggests that overriding without as-clause is valid, but the prose in that section do not mention the type-identicality.

I propose that after "Their declared types are identical." we add "The declared type is the type appearing in the 'as' attribute if present; in the absence of an 'as' attribute, the declared type is 'item()*' if a 'select' attribute is present, or 'document-node()' otherwise.

Or more precisely:

For this purpose, the declared type is the first of the following that applies:
				
* If there is an <code>as</code> attribute, then the type defined by that attribute.

* If there is a <code>select</code> attribute, then <code>item()*</code>.

* If there is a non-empty sequence constructor, then <code>document-node()</code>.

* Otherwise, <code>xs:string</code>.

Since this only pertains to xsl:variable and not xsl:param (which tends to be more malleable), I think it is a fair solution while still allowing processors to optimize for the (rather complex) default variable types.

For reference, a draft proposal erratum was published on 13 Feb 2019, E35, see:
https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E35

Reopening as I think we forgot one tiny little bit: existing examples in the spec.

I propose we change the existing examples where it is applicable. They are not necessarily wrong but as written they can lead to confusion, esp. in light of overriding. I think we only need to address the examples overriding is an option.

Luckily there's only a handful:

B.2 Stylesheet JSON
- variable $quot is private, leave as is

3.5.3.5 Binding References to Components
- variable $C has implicit type xs:integer, would benefit from as="xs:integer" for clarity
- example with xsl:override on $C, same, should have as="xs:integer" for clarity
- others are private/final, cannot be overridden

3.5.3.6 Dynamic References to Components
- in the Note, variable $get-order. Should have an as-clause as otherwise the type is item()* and that is not the intend here and can lead to errors.

3.5.7 Worked Example of a Library Package
- nothing to do, all xsl:variable have a type



Other variables do not appear under xsl:package and are therefore not open to misinterpretation.