Further to (4): the only place that relies on forming a wildcard union is in derivation by extension, and this states that when T is derived by extension from B, and the union of their wildcards is inexpressible, then the derived type uses the wildcard as defined on T. So, in the circumstances where the union of B|T is currently inexpressible, the union is effectively taken as T.

Now that's not a very nice rule; one would like union to be commutative.

It seems to me that it would be much nicer and simpler to drop rule 4, so that the union is always expressible and always commutative.

More thoughts on (4). I see now why (for example) the union of

<xs:anyAttribute notQName="##defined" id="P"/>

and

<xs:anyAttribute namespace="##local" id="Q"/>

is inexpressible: there is no way to express a wildcard that allows all attributes in the *absent* namespace plus all attributes other than globally declared attributes in other namespaces.

But consider the consequences. Wildcard union is used in only one place: where types are derived by extension. In this situation, if the base type is defined with wildcard P, and the extension type is defined with wildcard Q, then the actual complex type component will have wildcard Q. This hardly reflects the intent of type extension, whereby the extended type should allow everything the base type allows and more. From this perspective it would be better to combine the wildcards as:

<xs:anyAttribute/>

That is, the result of the union should be the "smallest expressible wildcard that has the true union as a subset", which can be constructed simply by dropping the notQName="##defined" constraint unless it is present on both wildcards.

Note that there is no compatibility issue with 1.0 in making this change. Although 1.0 had the same rule about how inexpressible wildcards were handled during type extension, all unions of 1.0 wildcards are expressible in 1.1; the only inexpressible wildcards in 1.1 arise when ##defined is used (which is a symptom of the lack of orthogonality in the design of this feature, but let that pass).

The WG discussed this issue in today's ftf.

We adopted a wording proposal which addresses most though not all of the
concerns expressed:

(1) the Note is deleted.
(2) the reference to multiple wildcards is retained (on the view that
it does not harm)
(3) rule 4 is gone.
(4) the proposal to make the union rule calculate a small expressible
superset is adopted.  We note in passing that we have not actually
proven that this is the smallest expressible subset, but it is easy
to calculate and understand, and it's not obviously larger than the
smallest expressible superset.

Fuller details of the proposal adopted will be posted either to the
IG list or to this bug report when doing so is more convenient than it
is at the moment.

Accordingly, I'm marking this as decided; we'll close it when the change
has been integrated into the status-quo document.

A further observation (which doesn't directly affect the resolution in comment #3). In comment #2 I observed that when type E extends type B, and the wildcard union is inexpressible, then under 3.4.2.5 rule 2.2.2.4, the {attribute wildcard} of the extended type is that defined in the xs:extension. However, this will almost certainly mean that the resulting type does not meet Derivation Valid: Extension, under 3.4.6.2 rule 1.3. So although the rules apparently recover from an inexpressible union wildcard, it seems that the attempt to recover will generally fail. Under the proposal of comment #3, the union will not only be expressible, but will also satisfy rule 1.3 which requires that the wildcard of the base type is a wildcard subset of the union.

The resolution of this issue has been incorporated into the status-quo
document generated during the face to face meeting in Redmond.
So I'm marking this issue RESOLVED.

Michael, as the originator, would you please indicate by closing or
reopening the issue whether you are satisfied with the disposition of the
comment?  If we don't hear from you in the next two weeks, we'll assume
you're happy.

The resolution is fine in principle, but there's some copy-editing needed on the text. In 3.10.6.3:

When one of the wildcard has defined in {disallowed names} and the other does not, then defined is not included in the union. This may allow QNames that was not allowed by either wiledcar. This is to ensure that all unions are expressible. If defined is intended to be included, then it is necessary to have it in both wildcards.

should read (see asterisked words)

When one of the *wildcards* has defined in {disallowed names} and the other does not, then defined is not included in the union. This may allow QNames that *are* not allowed by either *wildcard*. This is to ensure that all unions are expressible. If defined is intended to be included, then it is necessary to have it in both wildcards.