Actually, with an Option D approach, we can do one better: Get rid of all curlies within code. So rather than the current:

{{
input {$foo :number maxFractionDigits=0}
local $bar = {42 :number notation=scientific}
match {$foo :plural} {$baz :plural maxFractionDigits=2}
when 0 0 {{Croque monsieur camembert de normandie paneer.}}
when * * {{Brie pecorino swiss cream cheese halloumi boursin on toast.}}
}}

We could have:

.input $foo :number maxFractionDigits=0
.local $bar = 42 :number notation=scientific
.match $foo :plural
.match $baz :plural maxFractionDigits=2
when 0 0 {{Croque monsieur camembert de normandie paneer.}}
when * * {{Brie pecorino swiss cream cheese halloumi boursin on toast.}}

The key here is that . is not a valid name-start character, so it lets us detect the end of the expression without the }.

I appreciate the intent, but in terms of readability, I don't actually find that

.input $foo :number maxFractionDigits=0

is better than

.input {$foo :number maxFractionDigits=0}

In particular when input has a sigil. The sequence of .input $foo :number, with three different sigils, concerns me.

It's helpful to see where the expression actually is. It's also corresponds nicely with the placeholder syntax. {$foo :number maxFractionDigits=0} is exactly the same as an RHS in a declaration and as an expression in a placeholder.

Replying here to @aphillips from #526 (comment):

@eemeli suggested:

.match $numUsers :plural
.match $numDogs :plural
.match $activity :select
0 * * {{Nobody did anything with their dogs}}
* * * {{Everyone did everything with their dogs}}

What I don't like about this is that the match statements are laid out vertically while the keys are horizontal.

Just as an observation, given that whitespace isn't significant in the syntax, the above message would also be valid as

.match $numUsers :plural .match $numDogs :plural .match $activity :select
0 * * {{Nobody did anything with their dogs}}
* * * {{Everyone did everything with their dogs}}

and, conversely, the current syntax with its multiple selectors per single match could be presented as

.match
  {$numUsers :plural}
  {$numDogs :plural}
  {$activity :select}
0 * * {{Nobody did anything with their dogs}}
* * * {{Everyone did everything with their dogs}}

It is also tempting to reorder the match statements, which would break the selector (significantly change its meaning)

This is rather equivalent to reordering the arguments of a function, which I at least have not seen as a common problem irrespective of whether they are displayed on one or multiple lines. Is this a problem that you've commonly seen elsewhere?

One approach here would be to make the N=1 and N>1 cases different for match, so we'd have some explicit new syntax indicating that the selection is not on a single selector, but a [list] or (tuple) of selectors.

Then a common single-selector message could look like

.match {$count :number}
0   {{No messages}}
one {{{$count} message}}
*   {{{$count} messages}}

while a message with two selectors would be

.match ({$count :number} {$sender :gender})
(0 male)     {{No messages from him}}
(0 female)   {{No messages from her}}
(0 *)        {{No messages from them}}
(one male)   {{{$count} message from him}}
(one female) {{{$count} message from her}}
(one *)      {{{$count} message from them}}
(* male)     {{{$count} messages from him}}
(* female)   {{{$count} messages from her}}
(* *)        {{{$count} messages from them}}

@eemeli suggested:

One approach here would be to make the N=1 and N>1 cases different for match, so we'd have some explicit new syntax indicating that the selection is not on a single selector, but a [list] or (tuple) of selectors.

I'm not a fan of creating multiple ways to write messages. So I don't think this would work for me. If we want to indicate arity of .match, we should do so consistently.

One of my Seville "beer and tapas" syntaxes did that:

[? {$count :number} {$sender :gender}]
[0 male]   {{No messages for him}}
[0 female] {{No messages for her}}
[0 *]      {{No messages for this user}}
[one male] {{{$count} message for him}}
... yada yada...
[* *]      {{{$count} messages for this user}}

The question, I guess, would be: what user benefit derives from having syntax to explicitly close arity? The parser doesn't care. How will this help users? (I'm not saying, please note, that it won't)

This is rather equivalent to reordering the arguments of a function, which I at least have not seen as a common problem irrespective of whether they are displayed on one or multiple lines. Is this a problem that you've commonly seen elsewhere?

The ability of folks to make poor assumptions based on no evidence can be breathtaking in my experience 🤦. The thing here is that we're not "proper code" and match isn't necessarily "a function call". So if someone sees .match {$a} .match {$b} they might be tempted to think the variants are magically aligned somehow. Also, CAT tools might protect the values separately and not enforce "no reordering" (so the breakage might not be visible until runtime).

I think our syntax choices may have made this issue obsolete. @stasm, can I close this?

I don't think we've actually resolved this. In #529, we're dropping when, but we still need to discuss e.g. whether to leave the keys bare or [bracket] them. That links up with this discussion.

I labeled this LDML45 but think we will likely close this.