I think you're right. An unprefixed attribute does not (should not) imply the
namespace binding ""="". For attributes, no prefix means no namespace, and no
namespace binding is needed to establish this; there is no conflict between an
unprefixed attribute on an element, and a namespace binding such as
""="abc.uri" on the same element.

We believe you are correct - I will produce text to fix this here in this bug
report.

(In reply to comment #2)
> We believe you are correct - I will produce text to fix this here in this bug
> report.

I suggest we fix this by explicitly stating the exception for an attribute with
no namespace prefix in the three places where this problem occurs.

2.4.1 Insert
Bullet 3.b. 

No attribute node in $alist may have a QName whose implied namespace
binding conflicts with a namespace binding in the "namespaces"
property of $target [err:XUDY0023] <new>unless the namespace prefix
for the attribute is absent</new>.

Bullet 4.b. 

No attribute node in $alist may have a QName whose implied namespace
binding conflicts with a namespace binding in the "namespaces"
property of $target [err:XUDY0023] <new>unless the namespace prefix
for the attribute is absent</new>.


2.4.3.1 Replacing a Node
Bullet 4.b.

No attribute node in $rlist may have a QName whose implied namespace
binding conflicts with a namespace binding in the "namespaces"
property of $parent [err:XUDY0023] <new>unless the namespace prefix
for the attribute is absent</new>.

The WG accepted the solution in comment #3 in today's call.

I've added XQUTS test case id-insert-expr-094 as a result of this resolution.

Going this route, I think you would also need to make a change for 3.2.1
upd:mergeUpdates (2) f. and 3.2.2 upd:applyUpdates (1) f.  It seems, for
example, that upd:insertAttributes could inappropriately create a conflict with
upd:rename. 

Here is a slightly different route you may have already considered.  First, add
two new definitions:

[Definition: The implied namespace binding of a QName is the association of its
namespace prefix (or absence thereof) with its namespace URI (or absence
thereof).]

<new>
[Definition: The implied namespace binding of an element is the implied binding
of its name. ]

[Definition: The implied namespace binding of an attribute is the implied
binding of its name unless the name has no prefix in which case the attribute
does not have an implied binding. ]
</new>

Delete "QName of" text in the appropriate places.  For example:

2.4.1 Insert (3) b.
<old>No attribute node in $alist may have a QName whose implied namespace
binding conflicts with a ...</old>
<new>No attribute node in $alist may have an implied namespace binding that
conflicts with a ...</new>

(4) b (same)

2.4.3.1 Replacing a Node Bullet 4.b.
<old>No attribute node in $rlist may have a QName whose implied namespace
binding conflicts with a ...</old>
<new>No attribute node in $rlist may have an implied namespace binding that
conflicts with a ...</new>

In my opinion, this solution is cleaner because it is more up front about the
nature of conflicting implied bindings and it also eliminates the need for the
special cases.  Sorry in advance if I am missing something.

This comment is editorial, and we'll take your suggestions under consideration.

I decided to fix this by adding the following text to the definition of an
implied namespace binding, in addition to taking the approach shown in comment
#3:


Definition: The implied namespace binding of a QName is the
association of its namespace prefix (or absence thereof) with its
namespace URI (or absence thereof).] [Definition: Two namespace
bindings are said to conflict if their namespace prefixes (or
absence thereof) are the same but their namespace URI's (or absence
thereof) are different.] 

Update operations that result in conflicting namespace bindings
generally raise errors, as described in this document.

   <add>However, if the namespace prefix of an attribute is absent, it
   is in no namespace, and an update operation can create such an
   attribute in an element even though its implied namespace binding
   conflicts with a namespace binding in the "namespaces" property of
   the element.</add>

This feels nearly right....  But I'm not sure the reader will spot the subtle
difference between "implied namespace binding" in the first sentence, and
"namespace binding" in the second. A QName has an implied namespace binding,
and except in the case of a namespace binding ("", ?), the implied namespace
binding of a QName used as an attribute or element name will become an (actual)
namespace binding of the element, and a conflict between the (actual) namespace
bindings of an element is ALWAYS (not "generally", unless you mean the term
very pedantically) an error. The reason that the unprefixed attribute case
doesn't cause an error is that the implied namespace binding of the attribute
doesn't turn into an actual namespace binding on the element.

(In reply to comment #9)

I agree. I changed the text to:

However, if the namespace prefix of an attribute is absent, it is in
no namespace, and its implied namespace binding is not added to the namespace
bindings of its parent element. Therefore, an update operation can create such
an attribute in an element even though its implied namespace binding conflicts
with a namespace binding in the "namespaces" property of the element.