Document the introduction of the text-first mode

[stasm]

#474 pivoted into a discussion about variant patterns. Consequently, we now lack a good design doc about the text-first mode, a.k.a. unquoted simple patterns.

I can recall a few arguments discussed in the past in favor of code-first mode, which requires quoting all patterns:

• The consistency between simple and variant patterns, which can make the syntax easier to learn and easier to recall for some.
• Clear whitespace rules for all patterns.
• Fewer iteration hazards when adding declarations and variants.
• The ability to recognize a MF2 string in the wild just by looking at it, which hints at what sort of escapes and other rules can be applied if necessary.
• A distinct fallback syntax in case the i18n layer misbehaves -- if you see {Hello} in the UI, it means something's broken (a.k.a. pseudolocalization).

After Seville, we brought up the commonness of simple messages and questioned the cost of requiring to always quote them.

[gibson042]

I've raised the concept of "iteration hazard" elsewhere, and reiterated it in #526 as stemming from a fundamental distinction between "simple message" vs. "complex message" rather than the former being merely a degenerate case of the latter that happens to have no declarations and no matcher.

I also noted specifically in #526 (comment) that the desired unification can be achieved with a decision to start in code mode OR to start in text mode, but either way it is entangled with quoting—the requirements and interpretation for which must be consistent regardless of presence vs. absence of declarations/matchers (for example, introducing or removing an irrelevant singleton declaration and immediately following line feeds without changing any other content must not invalidate a message or change the significance of leading/trailing whitespace).

This concern may ultimately be rejected, but I hope that it would at least be acknowledged explicitly rather than as an implicit consequence of what participants considered to be isolated decisions. And I think this is the right issue for that.

[aphillips]

Valuable exercise but not required for the 45 timeframe

[aphillips]

I'm marking this as "Stale" for now, but welcome moving it into the 46.1 bucket if we think this is somehow still relevant/useful work. I note the existence of code-mode-introducer as a design doc. Recent changes to remove reserved-statement and its friends may have helped or hindered this effort.