TL;DR: Supporting implicit-true unvalued options would provide better UX for developers and translators and simplify validation.

Consider a function that accepts a keyword as its primary argument, say :brand for looking up the appropriate localized form of a brand name. Right now, this is achievable in two ways:

{|foo-thing| :brand}

{:brand key=foo-thing}

While both of these kinda work, neither is particularly pleasant to use. If #364 is accepted, the first one improves a bit:

{foo-thing :brand}

However, this order makes autocompletion impossible. Let's presume that the function registry is providing a known set of valid brands that may be localised, and it's only foo-thing. Then, by the time you've entered {fog-thing, there's no way to know if this is valid or not because the function hasn't been identified yet. To get there, you need to type all of {fog-thing :brand}, and then go back and fix your mistake.

Using the key= approach is a little bit better in this regard, but really those four characters are rather superfluous, and as with the positional argument, the value might be a variable. This means that it could be valid to write {:brand key=$foo}, and we wouldn't know until formatting time which brand we're localising. That's pretty powerful (much like dynamic message references, actually), but in many cases perhaps too powerful.

Instead, I think we ought to support unvalued options, so that this becomes possible:

{:brand foo-thing}

This has three benefits over the current alternatives:

1. Autocompletion can "just work", so writing MF2 feels more natural.
2. Option names cannot be variable, so we can validate the expression without consideration of runtime values.
3. Option basket validation becomes easier, because it depends on the presence of specific options, rather than the value assigned to them.

If we don't support unvalued options, we probably ought to introduce a way that the function registry can specify that a positional argument or an option value cannot be set by a variable. Though tbh that would probably make sense independently of this.