Markus Scherer

- "Placeholder" seems good. - "Option" for a key=value pair after a function name seems good. - "Argument" seems good for the input that a function works with. Not sure...

My memory from the March discussions with Mark & the TCs is that the formatting library should do first-match, and that other tooling (linters, localization tools) should complain about bad...

From my [proposed compromise syntax](https://github.com/unicode-org/message-format-wg/pull/266): Inside selected patterns, the selector argument variables must not be used with the normal `$` placeholder syntax – for example, the patterns in the preceding...

I think we should define one placeholder syntax that allows - a value (argument name or value literal) - a function by name - possibly with syntax indicating open/close as...

I agree that `{$arg :func opt=val}` is good. I am just lobbying for not allowing additional spaces in that placeholder. More optional spaces lead to sub-optimal readability and style fights....

I don't like giving certain markup special status in the syntax, and I get lost a bit in @eemeli's intro above, but his conclusion makes sense to me :-) I...

PS: It might be more obvious if a function name always has the same prefix, such as `:` in the current discussion. The open/close indicators could be *additional* prefixes, such...

Good points about different sets of options for different markup functions, rather than using a value literal to distinguish. In the discussion yesterday, several people liked allowing dots in function...

> The MFWG has recently spent a considerable amount of effort in coming up with a single starting point for our syntax that is sufficiently good to act as a...

I don't want to unravel the committee resolution where the details of formatToParts() are implementation-defined, and I don't think we need to. The output could be a string, or a...