There's an inconsistency re the meaning of "in scope".
Consider the example:

   for $v as xs:integer in (1,2) return
       for $v as xs:string in ("a", "b") return
           $v

At the point where the variable reference appears, what variables
are "in scope"? (Note that there's no question that the variable
reference refers to the xs:string variable.)

In one interpretation of the phrase, both $v variables are "in scope".
This interpretation is clearly the one in use in section 3.1.2:

    If a variable is bound in the static context for an expression,
    that variable is in scope for the entire expression. ...
    If a variable reference matches two or more variable bindings
    that are in scope, then the reference is taken as referring to
    the inner binding, that is, the one whose scope is smaller.

However, this interpretation has two problems:

(1)
It makes variable resolution dependent on information (size or
nestedness of scopes) that isn't present in the static context
(as defined).

(2)
It conflicts (more or less) with other passages in the spec:

(2a)
2.1.1 Static Context says:

    [Definition: In-scope variables. This is a mapping from expanded
    QName to type.]

where the word "mapping" presumably excludes the possibility that the
in-scope variables could contain two entries with the same expanded
QName. Mind you, this is a recent change. It used to say:
    This is a set of (expanded QName, type) pairs.


(2b)
2.2.5 Consistency Constraints says:

    For each (variable, type) pair in in-scope variables and
    the corresponding (variable, value) pair in variable values
    such that the variable names are equal, the value must match
    the type ...

If in-scope variables contains entries for both variables:
    ('v', xs:integer) ('v', xs:string)
then variable values must also have entries for both, e.g.:
    ('v', 1)          ('v', "a")
but then the consistency constraint might be taken to apply to all
four combinations, some of which violate the constraint. (You might
point out that only two of those combinations involve "corresponding"
pairs, but then if "corresponding" is so smart, why do we need to say
"such that the variable names are equal"?)

I'm not saying that the latter would be a reasonable stance, but
just that 2.1.1 and 2.2.5 appear to assume (and would certainly be
happier with) an interpretation in which *only* the xs:string variable
is "in scope" at the point of the variable reference.

---

Anyhow, I think the wording re "in scope" should be made more
consistent. As to which way, I think it would be simpler to change
the wording in 3.1.2 to use the interpretation that 2.1.1 and 2.2.5
appear to assume.