Your suggested EBNF allows
    $x transform with {} => upper-case()
and not
    $x => upper-case() transform with {}

I.e., it's the solution that you refer to as `TransformWithExpr > ArrowExpr`,
whereas you said that `ArrowExpr > TransformWithExpr` would make more sense.

So it's unclear which you actually prefer.

Oops :). You are correct on the ordering from the grammar. Thinking about this some more, I am not sure what is the best ordering.

The Update Facility 3.0 specification (in section 5.7) states that:

    N transform with { U }          [1]

is equivalent to:

    copy $v := N                    [2]
    modify $v!(U)
    return $v

This would mean that:

    N => A transform with { U }     [3]

would be equivalent to:

    copy $v := N => A               [4]
    modify $v!(U)
    return $v

while:

    N transform with { U } => A     [5]

would be equivalent to:

    copy $v := N                    [6]
    modify $v!(U)
    return $v => A

Thus, on a second look, I am not sure which of [4] or [6] would be most useful.

Another option would be to place ArrowExpr and TransformWithExpr at the same level:

    CastExpr ::= (ArrowExpr | TransformWithExpr) ( "cast" "as" SingleType )?
    ArrowExpr ::= UnaryExpr ( "=>" ArrowFunctionSpecifier ArgumentList )*
    TransformWithExpr ::= UnaryExpr ( "transform" "with" "{" Expr? "}" )?

This would mean that ArrowExpr and TransformWithExpr cannot be used in the same expression without parenthesis. This would probably be the best option, as otherwise there is the issue of how to handle multiple arrows, as in:

    $x => f() transform with {} => g()

A use case for mixing the two would be in something like:

    $x => doc() transform with { rename node . as "abc" }

which could be done with parenthesis if required:

    ($x => doc()) transform with { rename node . as "abc" }

I should point out that there is currently no great enthusiasm (that we know of) for doing the work to take Update 3.0 to Recommendation status. An Update *3.1* spec would be even less likely. So the point of this bug is probably moot. Unless you know of someone planning to add an Update Facility to an XQuery 3.1 processor?

I am working on developer tools (syntax highlighting, validation, etc.) for XQuery (the xquery-intellij-plugin for the IntelliJ IDE). I have recently added support for parsing XQuery 3.1, and am now working on supporting Update Facility 3.0, which is why I encountered this issue.

I have currently opted to implement option 3, as that is compatible with both specifications and does not introduce any additional functionality. If that changes with an Update Facility 3.1 in the future, I can make the necessary changes at that point.

According to the minutes of meeting #596 (2015-01-27), when the WG decided to change the precedence of TransformWithExpr wrt the XQuery 3.0 grammar, there was also some discussion of where it should fit wrt the XQuery *3.1* grammar (specifically ArrowExpr). The upshot is that, in our grammar/parser/applet system, if you request the 'xquery31' base with the 'update30' extension, you get the productions:
  CastExpr ::= TransformWithExpr ("cast" "as" SingleType)?
  TransformWithExpr ::= ArrowExpr ("transform" "with" "{" Expr? "}")?
  ArrowExpr ::= UnaryExpr ("=>" ArrowFunctionSpecifier ArgumentList)*
  UnaryExpr ::= ...

Note that, while this answers your original question, it isn't really an official answer, because xquery31+update30 isn't an authorized combination of specifications. (If Update 3.1 ever comes to pass, it might decide to place TransformWithExpr differently.) However, the likelihood seems high that it's the closest thing you'll ever get to an official answer.

Thanks for looking this up. Until an Update 3.1 specification is created, I am going to stick with using:

    CastExpr ::= (ArrowExpr | TransformWithExpr) ( "cast" "as" SingleType )?

As this is consistent with xquery31 and update30 without adding any additional behaviour that would be generated by using the constructs from the W3C internal grammar applet.