Or we could just remove the "[], (), {}" row from the table.

Well, square brackets are a kind of operator, in that e1[e2] performs an
operation, and it's important to know that it binds more tightly than "/", so
that e1/e2[e3] means e1/e2[e3] and not (e1/e2)[e3]. By contrast, () and {} are
not operators, and really don't belong in this table. But if we really want to
spell it out, e1[e2] has a bracketing function as well as being an operator in
its own right.

Other compound operators such as if/then/else aren't even present in the table.

And the sentence "Operators that have a lower precedence number cannot be
contained by operators with a higher precedence number." is certainly pretty
clumsy (I'd go so far as to say it is meaningless). While still informal, I
think it would be much better to say "Unless parentheses are used to change the
order of evaluation, operators with a high precedence number are evaluated
before operators with a lower precedence number".

I was asked at the XSL WG meeting on 5 Feb to produce a wording proposal to
resolve this.

Proposal:

For XPath and XQuery Appendix A.4:

(1) delete the sentence "Operators that have a lower precedence number cannot
be contained by operators with a higher precedence number."

(2) from the row labelled 19, delete the round and curly braces.

(3) Add after the table: "Note: parentheses can be used to override the
operator precedence in the usual way. Square brackets in an expression such as
A[B] serve two roles: they act as an operator causing B to be evaluated once
for each item in the value of A, and they act as parentheses enclosing the
expression B.
<XQuery-only>Curly braces in an expression such as validate{E} or ordered{E}
perform a similar bracketing role to the parentheses in a function call, but
with the difference in most cases that E is an Expr rather than ExprSingle,
meaning that it can use the comma operator.</XQuery-only>

The WG accepted this today at the face-to-face, I will add it to the XQuery and
XPath 2ed.