Maybe during parsing we should represent the ARRAY_REF if either there is no expression (i.e. ) or there are ,s some other way (perhaps NULL for , either TREE_LIST or TREE_VEC etc. for 2+) and then for builtin array ref if we see a parameter pack, try to expand it and error out on the  case (or empty pack) and for 2+ case turn it with a deprecation diagnostics into COMPOUND_EXPR(s) (unless from a pack, then error?).
And for the overloaded case handle it like call lookup (perhaps with diagnosed backwards compatibility fallback if the expression list would be valid compound expression and lookup would succeed for that compound expression as argument to single operand operator).
Created attachment 51595 [details]
Untested WIP, just template handling hasn't been added yet, so it is useful only without templates so far.
Created attachment 51596 [details]
Updated patch that handles even templates, including pack expansions.