Here are some queries for which we need to define behavior:

fn:QName((),"p:e")

element {fn:QName((),"p:e")} {}

Note that the element constructor will want to take the namespace URI from the
QName:

     If the atomized value of the name expression is of type xs:QName,
     that expanded QName is used as the node-name property of the
     constructed element, retaining the prefix part of the QName.

If we raise an error, as I suggest, then the following query raises an error,
even though we could assign a reasonable interpretation to it:

<e xmlns:p=uri>{ fn:QName((),"p:e")}</e>

The WG thinks that an error should be raised in this case. The part of the name
before the colon can't be a prefix, since we have no namespace URI to interpret
it with. The local name needs to conform to
http://www.w3.org/TR/REC-xml-names/#NT-NCName, so the local name doesn't contain
the colon either. So there's no useful way to interpret a name with a colon
unless there is a namespace URI to associate with it.

The resolution is to change fn:QName such that if first parameter is the
zero-length string or the empty sequence, then the second parameter can't have a
prefix in it.  If the second parameter does have a prefix, an error is raised. 

Please let us know if you agree with this resolution of your issue, by adding a
comment to the issue record and changing the Status of the issue to Closed. Or,
if you do not agree with this resolution, please add a comment explaining why.
If you wish to appeal the WG's decision to the Director, then also change the
Status of the record to Reopened. If you wish to record your dissent, but do not
wish to appeal the decision to the Director, then change the status of the
record to Closed. If we do not hear from you in the next two weeks, we will
assume you agree with the WG decision.

Yes, I'm completely satisfied with this resolution.