• Closes Preamble: unify local variable definitions and selectors? #252
• Closes Variants: should variant keys be delimited, too? #253
• Closes Start in "code" mode exclusively #256
• Closes Delimited text looks like code #275
• Closes Drop restriction on using keywords in the syntax #286

This proposal goes all-in on considering MF2 syntax as "code", and adds three keywords. As something of a side effect, this requires dropping the Plain construction.

let

Used to define the value of a local variable:

let $countInt = {$count :number maximumFractionDigits=0}

The syntax here is the same as previously in the preamble, with the addition of the let. The keyword is not strictly speaking necessary, but makes it easier to see that an assignment is taking place.

match

Defines the selectors for a multivariant message:

match {$countInt} {$user :gender}

Using match aligns with other pattern matching syntaxes, which more closely than switch maps to what we're doing in particular when selecting with more than one selector. Using select here wouldn't really work semantically.

when

Introduces a variant:

when 1 masc [...]
when many fem [...]
when * * [...]

Another possible alternative here would be case, but that somewhat overloads a term that we commonly use to refer to grammatical case.

Put together, these allow for a message that would with the current syntax be represented as

$countInt = {$count :number maximumFractionDigits=0}
{$user :gender}
1 masc [...]
many fem [...]
* * [...]

to instead read as:

let $countInt = {$count :number maximumFractionDigits=0}
match {$countInt} {$user :gender}
when 1 masc [...]
when many fem [...]
when * * [...]

While the latter clearly has more characters, it's much easier to figure out from it what's happening.

Dropping Plain

Because this PR makes it possible for a message to start with let or match, it makes it practically speaking impossible to continue supporting the undelimited "plain" form of simple messages while maintaining the language as LL(1). Therefore, it's dropped.

Practically speaking, it should still be possible to write an efficient detector for plain vs. MF2 messages, should it be desirable in some spec or environment built on top of the MF2 spec (such as the message resource syntax):

1. If a message starts with let, match or [, it may be MF2. If it is, in the first two cases, it will always contain a { within the first few tokens.
2. Plain messages may not start with a [ or contain a {.

As one benefit, dropping Plain means that MF2 will not provide two different ways to represent the same simple message ([Hello] vs. Hello).

Never mind the delimiters

This PR uses the current [...] syntax in its examples as that's what's currently on the develop branch. It is not meant to offer any opinion on #255 and the option of using {...} instead. However, it is relevant to note that this PR does effectively make it necessary to have some delimiters for message contents, concluding the discussion in #275.

Still not Turing-complete

Given that this change makes MF2 look more like code, it's good to note that we're still at most defining a deterministic finite-state machine. Message processing does not have access to anything like a stack, and cannot modify its own state; formatting calls are independent of each other. This holds even with custom formatting functions, as long as they are require to be pure functions.