This paragraph feels weird? It's unclear if we're trying to say that the "definitions" found here are normative. This also tangles with the reserves/custom identifier bear in a novel way.

Perhaps:

The MUST you propose is actually stronger than what we've currently in the spec, where the strongest language we use is

This paragraph should is intended to match/recall what's already elsewhere in the spec, rather than adding new normative text. It could be dropped completely, if that would be clearer?

The MUST is stronger, because it is effectively authoring advice. You're right that it probably should be a SHOULD. Perhaps something like:

Use a custom identifier for other attributes.

Indicate that yes is default?

Is there a reason attributes don't follow a similar structure to functions and their options here?

I don't think we've agreement that yes is the default. In fact, for expressions, I would think that the general default might in fact be no to indicate that a translator is not expected to make any changes to the expression.

Considering this a bit more, maybe something like translate=input or translate=|input,minimumFractionDigits| would be better? That would indicate which parts are expected to be translatable.

The default value is no when the attribute is not present, but yes when the attribute is present and has no value, right?

I don't like the values yes/no, but they are inherited from XLIFF (and its friends, such as ITS) and we should probably remain consistent with them (for portability at least)

Ah, that's a slightly different undrstanding of "default" than I'd had -- as in, the value that's applied if the attribute is not present at all.

I don't hate the yes/no as they're relatively legible and are perhaps easier to extend with other enum values than e.g. true/false would be. But as they're already in use by XLIFF, we should use the same values.

Why not just permit the "global" attributes on markup?

I don't understand what this means.

You're repeating attributes defined above. Why not make those like @comment global to both expressions and markup?

That seems like an editorial fix we could apply later, if it does hold that the annotations continue to match on expressions and markup.

It would be a bad idea for identically-named attributes to diverge. The sets aren't identical, of course.

digit size option?

That's limited to max 99, and we need to allow for limits greater than that.

Good luck with this one.

As in, we should not include it?

Measuring bytes will depend on some character encoding somewhere. Without an indication of the encoding (which this doesn't provide), there is no way to perform the measurement.

(FWIW, you're missing graphemes, which is another measurement (approximately "screen positions", but only approximately so).)

Lines depends on... font, font size, pixel width, line-breaking, hyphenation (insert more here) and are even harder to define that bytes.

Length limitations are a "fact of life" in localization, but badly defined mechanisms for them are not that helpful.

One option would be to leave out the units, and to let the implementation figure out what the limit means, something in the overlap of characters/code points/graphemes.