Consider syntax of `reserved-statement` some more

[Eemeli Aro]

A few issues were raised by @gibson042 in #529 (review) that we ought to consider and address:

• use of reserved-statement as interchangeable with a .match head rather than a full substitute for .match with its variants
• requiring reserved-statement to end with a list of expressions, precluding e.g. .strict true
  • ...and greedy consumption fails to capture the intuition of multiple statements in e.g. .strict true .local $var = {|val|}, instead parsing that as a single reserved statement subsuming the .local
• reusing the reserved-annotation reserved-body for reserved-statement, precluding e.g. .something opt1={$var} opt2={$var} because of the intent to prohibit e.g. nested expressions in annotations like {@reserved {|…|}}

[Stanisław Małolepszy]

@stasm:

What's the motiviation for putting reserved-statement inside complex-body? Do we expect other multivariant constructs than match? I think this may be building too much flexibility into the spec. Could we instead agree that any future keywords would go with other declarations?

@aphillips:

I think it was me who asked for reserved-statement to potentially be also a replacement for selectors. This would allow for a different type of selector in future syntax.

Perhaps this should be:

complex-body = quoted-pattern
             / (selectors 1*([s] variant))
              / reserved-statement ; which matches some-newly-unreserved-statement 1*([s] variant) 
                                   ; for some future statement

[Addison Phillips]

In another thread we discussed limiting reserved-statement to declarations. I have added this to the 2023-12-04 agenda.