(previously raised in WG email at
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2005Nov/0001.html -
transferred here by virtue of action A-281-01)

The expression

for $p at $p in EXP return $p

is not currently an error; it seems that the $p in the return clause is bound to
the second of the two declared variables, and that the first one is inaccessible.

This doesn't seem a useful thing to allow.

Discussion in the Working Group suggested a variety of positions on this. These
can be summarised by the following options:

A. Do nothing; the above construct remains allowed.

B. Introduce a rule that says the two iteration variables associated with the
same ExprSingle in a ForClause must have distinct names. (So the above construct
is prohibited, but "for $p in X, $p in Y return $p*$p" remains allowed.)

C. Introduce a rule that requires all the variables bound in a single FLWOR
expression to have distinct names

D. Disallow all shadowing of local variables.

In discussion, several people pointed to the common beginner's mistake of writing

let $x := 0
for $i in //item
  let $x := $x + $i/@price
  return $x

which is currently permitted, but does not do what this user expected. There is
a case for tightening the rules to catch this error. This would be achieved by
option C. On the other hand, the slight variant

let $x := 0
for $i in //item return
  let $x := $x + $i/@price
  return $x

would only be caught by option D.

There was some discussion of process/policy. Should we be making design changes
at this late stage of development? Perhaps we should, because it's only at this
late stage that we are able to collect real usability feedback.