Two comments:

1. This is tricky. If $t is evaluated eagerly (which we allow), then $pretty_t might contain a different sort of error (since $t contains a string that isn't a representative of a date/time value). Is this what we want here?

2. I find the examples hard to read vs. what we had before. I think the whitespace and multiline presentation of the original example (which is fine to delete) could be beneficial to replicate in the new examples.

The second point is now handled, but the first seems like a consequence of logic we already have—I'm just highlighting its transitive nature:

1. :now fails to resolve, so .local $t = {:now format=iso8601} resolves to the fallback value ":now".
2. Therefore .local $pretty_t = {$t :datetime} resolves to the same fallback value ":now", even in the current text—"When an error occurs in an expression with a variable operand and the variable refers to a local declaration, the fallback value is formatted based on the expression on the right-hand side of the declaration…", followed by an explicit example, and also "If a variable would resolve to a fallback value,
   this MUST also be considered a failure" text in Variable Resolution
3. Therefore {$pretty_t} resolves to the same fallback value ":now" for the same reason.

The main intent with the current transitive logic is to prevent the name of a local variable from ever showing up in the output, either during fallback or as the source of a formatted part.

Local variables should be considered message-internal implementation details that should never leak outside it.

...which I believe is demonstrated in the new example.

I found this confusing. You have to read everything here, including the next case, to understand how a fallback value could get into the variable. Unless you know about the transitive case, this appears to say "all variables". I would suggest putting the variable fails to resolve case first, then the transitive case (starting line 291) and end with an "otherwise" case for variables that resolve correctly but whose expressions fail.

Yes, that will be slightly repetitive in the last case.

I have refactored into "local reference" vs. "other" cases, which better maps to the "prevent the name of a local variable from ever showing up in the output" goal.

This sounds an awful lot like someone setting up a follow-up change to reserved syntax. 😇

Indeed. It would alternatively be possible to revert this privileging of non-function annotations that use function-like syntax (instead having them always fall back to �), but to me that seems unnecessarily future-hostile.

A "non-function annotation" is the same as reserved-annotation+private-use-annotation. Is there some reason to be elliptical about it?

I figure it's pretty much "function" vs. "other", because there's no differentiation here between private-use vs. reserved annotations. But your suggestion does more than just rephrase, because the instances of the latter do not necessarily start with a sigil-prefixed identifier (e.g., consider {@ reserved} and {>} and {&|quoted|}).

Those instances would not match my text and they would emit the logo. What's our intention here? Do we want to pass reserved/private garbage unmolested? Or turn them into the logo? My reading of the current text is that we make them into the logo unless they look like {^identifier something something} where we emit {^identifier} for some reason.

Current text is incoherent—the predicate of "expression with no operand: the function starting sigil followed by its identifier" covers non-function expressions, but the consequent cannot be applied to them. That can be fixed by always having such expressions fall back to the logo, or (as I have done here) by applying function-like treatment to those that use function-like syntax. But I consider it important for "function-like" to be defined narrowly enough to exclude e.g. {@spaceless|quoted|}.

It's almost coherent except for the possibility of reserved/private... which is what we're fixing here. Because reserved-annotation and private-use-annotation are permissive about content and because we don't have a construct for parsing inside them in the ABNF (nor, I think, should we...) I think emitting the logo makes some sense.

Putting myself in the shoes of a user, this is the rendered output of a message containing some placeholders that my implementation doesn't understand. If we emit their contents, yes, that might assist in debugging. But if shown to users it might contain code internal stuff. The logo basically is an admission that your implementation has no idea what this placeholder means. Does that make sense?

Note: it's probably important that we emit something as a way of preventing sneak attacks such as {{<scr{@omit me}ipt href=...>}}

Yep, I agree. But as I said elsewhere, I think always falling back to {�} even for function-like expressions is unnecessarily future-hostile.

There's a bit further down in the spec that probably ought to be highlighted here as well:

The intent with that is that even though our default fallback must guard against e.g. {$user :name} having a failure mode where a custom stringifier of the $user value gets called, dumping personal data into the output, there are still plenty of places where a better fallback than the default can and should be defined.

But it does mean that the space of fallback values cannot be considered exhaustive, and so a reserved expression producing {�} fallback now should not be considered a restriction on what might happen if we introduce a new meaning for its sigil later. Also, we should add language somewhere allowing an implementation to define separately the fallback behaviour for private-use sigils.

Put together, I think we could default to {�} fallback for reserved and private-use, but make it clear(er) that later spec versions or implementations supporting private-use can and should define something better.

I also think that it is important to indicate to the user that a fallback happened : that is, what is displayed to the user is not the intended result. One possibility is prefixing and/or suffixing with �.

@macchiati Perhaps? Presumably the presence of curly-bracketed garbage is an indicator. But having � present consistently would make it easier to find and easier to check for. If we did this, I'd make it a prefix so that we'd have fallbacks like:

{�}
{�$var}
{�|42.7 some literal|}
{�:function}
{�^unsupported}

I think this whole block should be moved to about line 262 so that the block is effectively structured:

The fallback value depends on the contents of the expression:

• expression with literal operand
  • emit the literal
• expression with variable operand
  • emit the variable
• expression with no operand but with a function
  • emit the function name
• expression with no operand but with reserved/private
  • if sigil+identifier, emit that, else fall through to:
• otherwise emit the logo

That also would be a behavior change, because not every variable operand is represented as a variable (specifically, a variable referencing a .local declaration is transparently treated as its resolved value).

Fair enough, but the above is a short representation of the whole. Do you disagree that reordering the text would make it clearer?

The fallback value depends on the contents of the expression:

• expression with literal operand
  • emit the literal
• expression with variable operand
  • if the variable references a .local emit the resolved value
  • else emit the variable
• expression with no operand but with a function
  • emit the function name
• expression with no operand but with reserved/private
  • if sigil+identifier, emit that, else fall through to:
• otherwise emit the logo

I think a single-level list of cases with no nested branches is clearer, so I've updated accordingly (basically just promoting "variable referencing .local" vs. "variable not referencing .local" into distinct cases).