The scope of variables declared in a group-by clause is governed by the general rules in 3.10.1:

The scope of a bound variable includes all subexpressions of the containing FLWOR that appear after the variable binding.

(This differs from the window clause, which has rules of its own).

This means that it is legal to write:

for $e in //employee
group by $s := $e/salary, $t := string($s)

But we don't say what this is supposed to mean. We say in 3.10.7:

For each pre-grouping tuple, the grouping keys are computed by evaluating the expression in the GroupingSpec and atomizing the result.

But $s is not present in the pre-grouping tuple, and therefore $t cannot be computed for a pre-grouping tuple. And we can't use the value of $s from the post-grouping tuple because that's only available after doing the grouping, and we can't do the grouping until we know $t. We could try to define some kind of model where the grouping is done in a sequence of steps each of which generates intermediate tuples, but it would be complex and probably lead to more surprises. Or we could try to do a syntactic transformation of the above to

for $e in //employee
let $s := $e/salary
let $t := string($s)
group by $s := $s, $t := $t

(which is the reverse of the current transformation)

As I can't see any practical uses that require this kind of construct, I think the simplest solution is to modify the scope rules so that in a group by clause, the variables declared within the clause are not in scope within that clause. We already have custom scope rules for the window clause, it's not a big deal to also introduce custom rules for the group by clause.