Proposed resolution: add an "optional static error".

[XTSE0813] It is a static error if the effect of applying namespace aliases to the attributes of a literal result element is to cause two such attributes to have the same expanded name. Because previous versions of this specification failed to identify this error condition, reporting of this error is RECOMMENDED but not REQUIRED. If the error is not reported, the effect is implementation-dependent; for example, one of the attributes may be output and the other ignored.

This basically licenses processors to report an error while not making existing processors non-conformant.

I think you are saying that, without intervention, the theoretical outcome of your fragment would be something along these lines:

 <test x:foo="2" y:foo="3" xmlns:x="urn:x" xmlns:y="urn:x" />

I think this can happen without xsl:namespace-alias (i.e. with xsl:attribute), except that in that case we already have a rule that the last attribute is chosen.

First I thought the following statement from the section on Namespace Fixup helps us:

"Namespace fixup may, if necessary to resolve conflicts, change the namespace prefix contained in the QName value that holds the name of an element or attribute node. This includes the option to add or remove a prefix."

But it doesn't appear to allow removal of an attribute, which is required to solve this.

However, under "constructing complex content" we have:

9. If the sequence contains two or more namespace nodes with the same name (or no name) and the same string value (that is, two namespace nodes mapping the same prefix to the same namespace URI), then all but one of the duplicate nodes are discarded. 

and:

10. If an attribute A in the sequence has the same name as another attribute B that appears later in the sequence, then attribute A is discarded from the sequence. Before discarding attribute A, the processor may signal any type errors that would be signaled if attribute B were not present. 

---

If we apply these rules to your example, I think that namespaces belonging to "x" and "y", after xsl:namespace-alias is applied, and both having the same URI, they follow rule #9. 

Then the names of the attributes are equal, and they follow rule #10, the later attribute wins.

> I don't think the spec gives us any guidance which of the two options we 
> should choose.
I think that we should follow the constructing complex content rules here. Even though your example has an LRE, it'd make sense to be consistent. I mean, if you'd have:

<a x:foo="3"><xsl:attribute name="y:foo">4</xsl:attribute></a>

you'd expect the same outcome as for the LRE. While presently the line above would properly keep "y:foo" (though not necessarily the prefix, see rule #9 and depending on xsl:namespace-alias), and no error is raised, rewriting the code as LRE should keep this behavior.

The difference from the case with xsl:attribute is that (a) the order of attributes in the LRE is undefined, so there is no way of knowing which one will be "last", and (b) the situation can be detected statically.

It seems to me that there's no way anyone would deliberately write code that does this, given that the outcome is entirely implementation-dependent, and therefore a static error seems useful.

(In reply to Michael Kay from comment #3)
> [...] It seems to me that there's no way anyone would deliberately write code 
> that does this, given that the outcome is entirely implementation-dependent, 
> and therefore a static error seems useful.
Valid points, I'd agree.