An equivalent bug was raised some time ago against XSLT 2.0 - see bug #5857. This arose "in real life" from a user trying to generate an XML Schema as the output of a transformation.

Consider the following query:

<s:complexType xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns="http://t.com/">
  <s:element ref="abcd" xmlns=""/>
</s:complexType>

Intuitively, one might imagine that the output would be the same:

<s:complexType xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns="http://t.com/">
  <s:element ref="abcd" xmlns=""/>
</s:complexType>

But it is not. The correct output is:

<s:complexType xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns="http://t.com/">
  <s:element ref="abcd"/>
</s:complexType>

Which is not what the user wants: the xmlns="" is there to ensure that the QName-valued ref attribute is a QName in the null namespace, not in namespace http://t/com/. 

(As it happens, Saxon produces the output the user would like, which is incorrect against the current spec.)

The reason is that we construct the result tree bottom-up. First we construct the s:element element, with a single in-scope namespace xmlns:s="http://www.w3.org/2001/XMLSchema". Then we construct the s:complexType element with two in-scope namespaces corresponding to those declared in the source. Then the child element is copied, and namespace inheritance is in force, so the copied child acquires a namespace binding for http://t.com/ from its new parent.

The solution being proposed (not yet approved) for XSLT is that the default namespace should never be inherited. Specifically, change 3.7.1.3 rule 1.e.ii.D.II to read:

If copy-namespaces mode specifies inherit, the copied node inherits all the in-scope namespaces of the constructed node *other than any binding for the default namespace*, augmented and overridden by the in-scope namespaces of the original element that were preserved by the preceding rule. If copy-namespaces mode specifies no-inherit, the copied node does not inherit any in-scope namespaces from the constructed node.

The justification for treating the default namespace differently from other namespaces is that the semantics of a namespace undeclaration are different. Whereas the undeclaration xmlns:p="" makes the prefix p unavailable for use, the undeclaration xmlns="" causes the prefix "" to refer to the null namespace "" - so in many ways it behaves more like a redeclaration than an undeclaration. In particular, in the example under study, the user wrote xmlns="" because they wanted to define a specific binding between the empty prefix and the null namespace.

(Another approach that might work is to treat xmlns="" as creating a namespace binding. But that would create compatibility problems for applications using the namespace axis, or its equivalent in-scope-prefixes().)