What if an implementation extends a built-in function with additional options -- could those implementation-specific options be namespaced?

Yes. In fact, we show this in the examples.

I think it might be clearer for this sentence to say something like "Built-in functions and standard options to built-in functions..."

I'm not sure if "standard" is the right word there, but I mean the options specified in the standard registry (if it's correct to call that the standard registry).

What if name contains more than one colon?

Removed the ability of colon to appear in name. Note that this makes our names match NCName (which I cite in this revision). This helps reduce the "sorta like an" XML name thing.

There is no definition for name-body, but this grammar is ambiguous if that is intended to be name-part—which ends in *name-char and therefore can itself include colons. For example, would parsing "foo:bar:baz" as a name be { namespace: "foo", name-part: "bar:baz" } or { namespace: "foo:bar", name-part: "baz" } or { name-part: "foo:bar:baz" }?

I agree that we need to fix the ambiguity here. I think #519 is the right place to do it, so that we have a chance to holistically look at the syntax and consider other productions. We don't need to block this PR.

My preference, however, would be to make this PR complete, i.e. fix the ambiguity somehow before merging. Two options for temporary solutions:

• Use / as a temporary namespace separator.
• Make namespace consist only of name-start characters.

I see that the changes to syntax.md mention NCName. @aphillips do you intend to factor NCName into message.abnf in this PR?

For the sake of sanity, the namespace separator character should not be a valid name-part character.

Removed colon (which I had intended in the first place 🤦🤷‍♂️🙈). As noted above, this makes us match XML names.

Does "implementation-defined" include the implementations of the default registry's functions? Or do you mean other functions built into the implementation, but not present in the default registry?

I'm thinking of going back to the design document and adding some use cases to illustrate these. In this case, I mean "non-default registry functions". I will add text to clarify.

Suppose you're Mihai and you're creating the ICU4J implementation. The :datetime function in the default registry might be backed by com.ibm.icu.text.DateFormat as an implementing class. There's no need to prefix :datetime for that. That's just implementation.

Mihai might want to expose skeleton though. That's not (currently) a default registry option. So he'd prefix it as icu:skeleton in his implementation.

Suppose he then goes on to implement com.ibm.icu.text.DateIntervalFormat as a function. That's not in the default registry, so it gets :icu:dateinterval and its options might or might not be namespaced.

Suppose Mihai goes on to implement an SPI for custom functions. Suppose I write my own date formatter. It doesn't replace the one in :dateformat, so it gets a prefix like :app:dateformat. The standard options might not be prefixed, but my custom options would be. ICU's options would probably be unrecognized to me. So you could see expressions like:

{$now :datetime icu:skeleton=yMMMd}
{$now :icu:dateinterval end=$then skeleton=yMMM}
{$now :app:datetime dateStyle=short :app:wonderfulness=high}

Suppose you're a tool implementer working with messages written for Mihai's implementation with my add-on. When you see a namespace prefix, that tells you that the function or the option is non-standard. The prefix might tell you where to look for the add-on registry or at least be something that you can key locally. Tool consumption is a key reason for namespacing.

Adding these use-cases in form of such user journeys sounds great. I'll be happy to contribute. Open a new PR?

Might be best to add a subsection to "Function Resolution" that collects these directions about what's possible and recommended for implementations and users to do with functions?