I think this part of the sentence doesn't belong. The attributes need to be resolved if they are present. Whether they have an impact on formatting is up to the functions or processing involved in the formatting itself. Also, it should be noted that the attributes almost certainly "pass down" to parts during formatting (so that the caller can access them, if needed).

I'm not so sure about attributes getting passed as such to formatting or selection functions. If that makes sense, then why not pass them as function options?

Locale is special because

1. It's already handled as special by existing formatters, and
2. it may get a separate field in the formatted-parts output.

I can see how e.g. timezone could be handled similarly specially by setting up some aspect of the environment before a formatter call rather than considering it as a function option, but for that I'd expect it to be a thing that the implementation does, and which affects the formatter only indirectly.

The attributes need to be resolved if they are present.

That's not really in line with what we're saying about other ignored code. For example, we allow an implementation to ignore errors in expressions that aren't needed for the current formatting. Similarly, we should ignore errors in attributes that don't impact the formatting.

The attributes need to be resolved if they are present.

That's not really in line with what we're saying about other ignored code. For example, we allow an implementation to ignore errors in expressions that aren't needed for the current formatting. Similarly, we should ignore errors in attributes that don't impact the formatting.

The attributes need to be parsed, even if they are not recognized. The parser does not necessarily know what is supported downstream or in an implementation.

Similarly, we should ignore errors in attributes that don't impact the formatting.

Depends on what "error" means. If there is a syntax error, we can't ignore that, no? (some of this is about what "we" means here: It is up to the function to decide if an attribute is "bad" or just to ignore it. "Our" job is to get the options and variables to the function.)

Define "valid" here. Is @locale=|hello world| valid? What about @locale=dead-beef (sorta BCP47-like)?

That's defined in the expression attribute resolution section.

The problem here is that "valid" isn't clearly attached to @Locale or expression attribute.

If this were written upside down, it might be clearer, e.g.

Let expressionLocale be the message locale from the formatting context.
If the expression contains a well-formed @locale expression attribute, let expressionLocale be that value.

I would expose the expression attributes here also. Locale may not be the only one--I certainly have timezone in mind and other attributes may be provided by the implementation or our specification that affect the formatter.

At least for the JS Intl.DateTimeFormat, timeZone is a regular option. Should we not handle it as such?

For other attributes, there is this below:

Implementations MAY assign meaning during formatting to other expression attributes

Should the text here make a reference to that as well, or is that implicit permission sufficiently clear?

For other attributes, there is this below:

Implementations MAY assign meaning during formatting to other expression attributes

Should the text here make a reference to that as well, or is that implicit permission sufficiently clear?

You're permitting implementations to assign meaning, but here I'm suggesting that functions can assign meaning to attribute values, including those unknown to the implementation. They can only do this if they have access to the values, of course.

Why would such a value be defined in the syntax as an expression attribute rather than as a function option?

How about just allowing unrecognized attributes to be ignored?

Because then we could not later assign a meaning to them without potentially breaking user code.

Reserving a namespace is a separate thing from ignoring unrecognized values. These can work in tandem. An MF2.0 implementation would ignore the unrecognized value @foo that MF2.1 unreserves, as well as @_bar that some other proprietary implementation is using.

Alternatively (and as I suggested elsewhere), as long as the values are syntactically correct, the implementation can just parse the values without imputing meaning to them and pass them. It only has to apply validation rules to attributes it "knows" (and do we define an error for that???)

Consider the following hypothetical, in a world where we allow implementations to assign their own meaning to any attributes not explicitly defined in the spec like @locale and @translate:

Let's say that an implementation defines @fallback to provide a value that should be used for a placeholder, should its formatting fail for whatever reason. This doesn't really make sense as a function option, because it's covering the behaviour of what happens if the function throws an error. Other implementations could just ignore this attribute, and use the spec-defined fallback representation.

Then let's say that in a 2.1 version of the MF spec we'd like to define @fallback to mean a fallback locale to use, if the function doesn't support the message locale, or the one set by @locale. This hypothetical attribute would have the same semantics as @locale, but it would append values to the language priority list rather than replacing it.

But in this world we could not do that without potentially breaking userspace, because an implementation as defined above could exist, along with a pre-existing body of messages using @fallback with a completely different meaning. In this case, the meanings of "fallback" are quite different, but even should they align, it's very likely that the detailed implementation and requirements could differ for the attributes. In other words, we would not be able to define any future attributes in the spec without a danger of breaking userspace.

I remarked on this before: this is too opinionated. Just because you are thinking of translator hints at this moment does not make them them the sole or even primary reason for this feature.

I suspect we should take a moment to agree on requirements/design before adding a feature like this: we should work as efficiently as possible, but not headlong.

The problem here is that "valid" isn't clearly attached to @Locale or expression attribute.

If this were written upside down, it might be clearer, e.g.

Let expressionLocale be the message locale from the formatting context.
If the expression contains a well-formed @locale expression attribute, let expressionLocale be that value.

We also need to be careful here. Does "invalid" include the language tag's validity? That is, are we requiring that the implementation check the tag's contents? I think that's a job for e.g. Intl.Locale.

If you made the change I suggested on the previous paragraph, some of this paragraph would become irrelevant (we'd have already said that the value was a sequence of language tags). Then this paragraph could say:

Then we probably need to add somewhere:

To resolve the value of an @locale...
If the value is empty, emit an error (I think?)
If a literal, split on comma, trim, check for well-formed tag
If a variable:
- if an array...
- else if a literal...

I suspect this is wrong. Implementations should not be required to support attributes that they don't recognize or impute meaning. So they are "ignoring" them from that perspective. But they have already parsed them. If I implement @_foo in my functions and impute meaning to whatever I assign to @_foo at the expression level, then I'd like the implementation I'm running on to pass the value to me (pretty please), even though the impl doesn't know what it means. Otherwise "private use" expression attributes can't work (as anything other than translator instructions)