The final para of §6.2.5 is:

When recognising arelational_expression (§12.12.1) if both the “relational_expressionistype” and “relational_expressionispattern” alternatives are applicable, andtype resolves to an accessible type, then the “relational_expressionistype” alternative shall be chosen.

The rest of §6.2.5 is about disambiguationtype_argument_list, and this para is just about
lost after the disambiguation examples. This information should be relocated to §12.12.1 (relational_expression) and/or §12.12.12 (is operator).

In §12.12.1 following the grammar forrelational_expression &equality_expression there
is:

Note: Lookup for the right operand of theis operator must first test as atype, then as anexpression which may span multiple tokens. In the case where the operand is anexpression, the pattern expression must have precedence at least as high asshift_expression.end note

“must have” sounds rather normative for a non-normative note, and the statement “precedence at least as
high asshift_expression” is rather curious without further explanation – if precedence prevents
the writing of what is required then using parenthesis is usually indicated, which is supported
byexpression, and something the Standard doesn’t repeat all over the place…

In §12.12.12 and its two subclauses on the is-type & is-pattern operators there is no mention of
disambiguation between them or of any precedence requirements.

The current text in §6.2.5 probably needs to be incorporated into §12.12.1/12, and that in §12.12.1 at minimum revised.

Note thatis will change in v9, including the is-type/is-pattern distinction,
which should be kept in mind in any fix-up now. Marking this as v8 for now…