I personally would have thought it reasonably clear that an XPath expression between curly braces in an AVT is "an XPath expression contained in [that] attribute": though if other people feel it needs spelling out then we can spell it out.

I'm not happy about the addition "The attribute does not affect other names <new>that are used solely for cross reference purposes in stylesheet-defined objects</new>..." As written, we've listed all the places that *are* affected, and the final sentence says that if the name isn't in one of the places listed above, then it isn't affected. The "other names" referred to here is a much broader list than your clause suggests, for example it includes attribute names in path expressions, names of output methods, etc. With your change, it's not clear whether names appearing in neither list are affected or not.

The main point of doubt arose from the end of 5.2:
The attribute does not affect other names, for example function names, variable names, or names used as arguments to the key or system-property functions.

It actually should affect the first argument of key() until the point that the expression is reduced to a single string, which must be a valid XML name. Then, if that string is an NCName, it should not have an effect. That way, it will sync up with xsl:key/@name, where x-d-n does not have an effect. It should always affect the second argument to key(), even if typed as xs:NAME, because that argument is not being used as a cross-referencing name. (But it is being used as a value to be tested against @use values; see below.)

I think the WG intends the same about AVTs: x-d-n affects what is inside the braces, but once that is reduced to an NCName, it does not affect the name.

It would be useful to say something at 16.3.1, addressing @name briefly, because there is also potential vagueness between the effect of x-d-n on @use
vs. the sequence constructor as content. It's clear enough that x-d-n affects @use as an expression, and @match as a pattern also, but its effect on the content constructor should be clarified. It should affect the expressions found in the content constructor (e.g., xsl:when/@test), but not the resulting values nor resulting @use values, should they happen to be valid NCNames.

BTW, I did not feel confident that the list of items affected by x-d-n at 5.2 was an exhaustive list. Now that I see the comments in this bug entry, I think the policy regarding path expressions is that it only affects source-facing names, not output-facing names. I think that it affects type names facing both ways.

x-d-n only affects the interpretation of unprefixed QNames that appear statically somewhere in the stylesheet. It has no effect at run-time, and it has no effect on names written in the form of string literals. Perhaps that's the distinction you are grappling with.

It's also true, as you're suggesting, that the list of names it affects are essentially the names of elements appearing in source documents. For names of objects in the stylesheet (and for names of attributes anywhere), the rule is "no prefix means no namespace". For names of constructed elements, the rule is "no prefix means use the default namespace (xmlns='uri')". Type names were included, I  think, because of a feeling that types would often be in the same namespace as the input document and so should be treated consistently.

I'm not sure I understand why you draw out the content of an xsl:key element as a special case. The content consists of XSLT instructions, and they are affected by x-d-n in exactly the same way as XSLT instructions anywhere else in the stylesheet.

The editor was asked to propose editorial changes to remove any sources of uncertainty from the meaning, addressing the comments made above.

Suggested changes:

In 5.2 after "contained in an attribute of that element" add "(including XPath expressions in attribute value templates)".

In the last para of 5.2, change "The attribute does not affect other names, for example function names, variable names, or names used as arguments to the key or system-property functions." to "The attribute does not affect other names, for example function names, variable names, or template names, or strings that are interpreted as lexical QNames during stylesheet evaluation, such as the [effective value] of the name attribute of xsl:element or the string supplied as the first argument to the key function."

The changes proposed in comment #4 were accepted by the WG and have now been applied.