Duplicate Option Name error is a data model error? This is where an implementation might detect it.

Also, note that other text a bit later seems to suggest that this isn't fatal:

Errors MAY be emitted during option resolution, but it always resolves to some mapping of string identifiers to values. This mapping can be empty.

"always resolves to some mapping" means that the option array is returned. For at least some messages, the results might be recoverable (i.e. only replacing the expression with the fallback rather than the whole message)

The current formatting spec language assumes that it's dealing with a valid message, i.e. one with no data model errors. Duplicate Option Name errors are primarily defined in errors.md, but for messages coming from syntax, they're also defined here:

So in order to get to this point in formatting, the current spec text must presume that this error has already been checked, and that therefore the condition for triggering it can't happen. So this statement should be removed to remove the current uncertainty it presents.

We also explicitly only allow for Resolution and Formatting errors to be ignored in expressions that aren't being formatted, and not data model errors:

Thanks @eemeli. You're right, we do have that text in errors.md, etc.

I guess what I'm grappling with is: did we make the right choice here. @catamorphism and @mihnita might weigh in about how they've implemented the checks required by data model (that is, when do they check for duplicate options or missing variant keys or duplicate declarations). I'm fine with blowing up the message for all of these with the possible exception of duplicate option names (and even there I still want to blow up)

Like I mentioned in #703 (just repeating it here to make the threads easier to follow) my implementation does a "static checking" pass for data model errors that are not checked during parsing, which is consistent with what @eemeli is saying.