I believe it is intentional, though I would have trouble proving it: the history is long and tortuous.

Note that in XSD 1.1 the lexical space of xs:anyURI is the set of all strings of XML characters, so the question becomes (in the American parlance) moot.

At the heart of the problem is that the namespaces recommendation (deliberately, I understand) does not make it a well-formedness error if a namespace name is not a valid URI (or IRI, in the case of the 1.1 specification). There is clearly an intent and desire that namespace names should be URIs/IRIs, but there is no error defined if they are not. 

This point can itself be disputed. The rules for conformance of documents to the Namespaces spec are circular: Section 7, Conformance of documents, says "A document is namespace-well-formed if it conforms to this specification". 

Section 8, on conformance of processors, says "a processor must report violations of namespace well-formedness, with the exception that it is not required to check that namespace names are legal IRIs." which suggests that documents using illegal IRIs are NOT namespace well-formed; but it is explicit that the parser isn't required to reject such documents, and if the XML parser isn't going to reject them then it doesn't make much sense for downstream software to reject them.

So I think all of our specs have moved in the direction of removing any requirement that namespace names be valid IRIs.

Doesn't this then mean that the following text from 2.4.5 URI Literals is now redundant?

"However, an implementation may raise a static error [err:XQST0046] if the value of a URILiteral is of nonzero length and is not in the lexical space of xs:anyURI."

https://www.w3.org/XML/Group/qtspecs/specifications/xquery-30/html/xquery-30.html#id-uri-literals

The sentence becomes redundant once we move firmly to XSD 1.1.: or at any rate, it needs changing.

Note that the contents of a URILiteral do not always represent a namespace. If the URILiteral is a relative URI, in some contexts for example a collation URI, then it needs to be resolved against a base URI, and in these cases I think there is still an error condition if the value is neither an absolute URI nor a relative URI: but it's no longer appropriate to define this error by reference to the xs:anyURI data type.

Indded, but for implementations following the XSD 1.0 definition, in this one place in the specification the check being made everywhere else has been dropped.

I'd like to see XQuery follow XSLT 2.0 on this, with an error which the implementation MAY raise.  Of course, an implementation following XSD 1.1 on this would never have cause to raise such an exception.

The Working Group has decided to resolve this by endorsing comment #3. We want interoperability, and prefer not to allow some implementations to raise an error that others would not in this context.

I've reopening this bug in light of the expected changes regarding XQST0046.

If an implementation is at liberty to prevent use of a braced URI literal because it doesn't match RFCxxxx, then it should be possible to prevent creation of namespace URIs of this form.

Here's a summary of the inconsistency which is currently in the specification.

If X is an invalid URI then at the moment:

element Q{X} { } <-- MAY RAISE XQST0046
namespace "foo" { "X" } <-- NEVER RAISES AN ERROR

(In reply to comment #7)
> Here's a summary of the inconsistency which is currently in the specification.
> 
> If X is an invalid URI then at the moment:
> 
> element Q{X} { } <-- MAY RAISE XQST0046
> namespace "foo" { "X" } <-- NEVER RAISES AN ERROR

In today's telcon, we agreed to allow implementations to raise an error for computed namespace constructors, but not the same error used for URI literals.

This error will be a dynamic error, defined in terms of xs:anyURI.