The ambiguity is already there; every identifier need to a context of applicability; a bare URI might identify any kind of Web resource, and it's only when it's contextualised -- e.g., with a href attribute, an img element, an xmlns attribute -- that will you know what to do with it.
The fact that a URI scheme doesn't tell you the type of what's on the other end is a feature, not a bug.
The problem with not having a normal way to turn QNames into URIs is that different specs that want to identify the same things might use different algorithms for shifting between them, and therefore be incompatible.
]]>The problem is when two languages attach, lets say, a description to a single QName, for instance the purpose of an element and the description of an interface. Of course these descriptions will differ. When the knowledge is combined, according to DaveO's approach we'd end up saying that this QName has both descriptions. This would be confusing at best.
And the problem you mention should not occur because WSDL, when reusing XML Schema type QNames, will use XML Schema's way of turning those QNames to URIs, whereas WSDL's QNames will be turned to URIs using WSDL's algorithm.
]]>