I suspect you are right, but we want to look at this carefully. 

You claim this: 

element(An, T) would not be a subtype of element(An)

That would be a bug. This is equivalent to saying that the following judgement returns false in http://www.w3.org/TR/2014/WD-xquery-31-20140424/#id-itemtype-subtype:

subtype-itemtype( element(An,T), element(An))

Ai = element(An,T)
Bi = element(An)

Rule 14 is the only one that can match this case:

<quote>
14. Bi is either element(Bn) or element(Bn, xs:anyType?), the expanded QName of An equals the expanded QName of Bn, and Ai is either element(An), or element(An, T?) for any type T.
</quote>

Let's review the meaning of the syntax for the two element tests according to http://www.w3.org/TR/2014/WD-xquery-31-20140424/#id-element-test :

<quote>
3. element( ElementName , TypeName ) matches an element node whose name is ElementName if derives-from( AT, TypeName ) is true, where AT is the type annotation of the element node, and the nilled property of the node is false.

Example: element(person, surgeon) matches a non-nilled element node whose name is person and whose type annotation is surgeon (or is derived from surgeon).

4.  element( ElementName, TypeName ?) matches an element node whose name is ElementName if derives-from( AT, TypeName ) is true, where AT is the type annotation of the element node. The nilled property of the node may be either true or false.

Example: element(person, surgeon?) matches a nilled or non-nilled element node whose name is person and whose type annotation is surgeon (or is derived from surgeon).
</quote>

Having looked over the spec, I think this bug makes a valid point and this needs fixing.

I think Benito is correct in the sense that rule 14 is incomplete. However, I think the missing case is covered by rule 16:

16. Bi is element(Bn, Bt?), the expanded QName of An equals the expanded QName of Bn, Ai is either element(An, At) or element(An, At?), and derives-from(At, Bt) returns true.

If we set Bt = xs:anyType, then for any type T we know that derives-from(At, Bt) is true, so rule 16 becomes

16a. Bi is element(Bn, xs:anyType?), the expanded QName of An equals the expanded QName of Bn, Ai is either element(An, T) or element(An, T?) for any type T

which is identical to the amended rule 14 proposed by Benito. Except that rule 14 also covers the case where there is no type name.

I think therefore that rule 14 could be replaced with the rule

14. Bi is element(N), and Ai is either element(N) or element (N, T) or element(N, T?), where N is any QName and T is any schema type.

leaving rule 16 to take care of the case element(Bn, xs:anyType?).

Note, I've simplifed the rule by assuming that we can take it as read that the QName N can be written in different ways and still be the same QName - but perhaps we shouldn't do that here unless we do it throughout all the rules.

I got that wrong. 

The reason rule 14 covers the element(B, xs:anyType?) case is that we want to make element(N) a subtype of element(N, xs:anyType?), which would not be the case under rule 16 alone.

So I think the lowest-risk fix, as suggested, is to change rule 14 as suggested to say:

14. Bi is either element(Bn) or element(Bn, xs:anyType?), the expanded QName of An equals the expanded QName of Bn, and Ai is either element(An) or element(An, T) or element(An, T?) for any type T.

The working group decided on the following resolution at the 2014-11-25 teleconference:

RESOLVED: to address bug 27175 by making the change proposed in
comment 4.

Confirmed that the proposed change has been applied in the current draft.