Further thoughts on this. There now seem to be four ways of controlling what happens when a wildcard matches/does not match a global element/attribute declaration:

strict: validate if defined, error if not

lax: validate if defined, untyped if not

skip: untyped if defined, untyped if not

notQName=defined: error if defined, untyped if not

One practical implication of making this a fourth option on processContents (let's say processContents="undeclared") would be that it would affect the rules for wildcard intersection and union. Currently the rules for attribute groups with multiple wildcards are pretty strange: you get the intersection of the allowed namespaces, but the processContents of the first wildcard. Moving the notQName=defined so it became a processContents option wouldn't suddenly set the world to rights on this, but it would ensure that you don't end up with crazy combinations like processContents="strict" notQName="##defined".

(I'm not sure where this leaves notQName="##definedSibling", however - that's another carbuncle, if you ask me.)

Using "processContents" for the "not-in-schema" wildcard support was one possibility the WG considered, because its interaction with global declarations is like the opposite of "strict". The WG decided not to do it. We may be able to recover the reasoning by fishing through the minutes.

One way to look at the interaction between {namespace constraint} and {process contents} is that the former controls what to match, and the latter controls what to do after the match. For "not-in-schema" wildcard, one could argue that the test should fail at the "match" step, which makes {namespace constraint} (hence notQName) a better choice.

Also note that "strict" = "can be validated (against a declaration or a type)" != "matches a global declaration". i.e. having an xsi:type would satisfy strict (and lax), without a matching global element declaration.

The WG discussed this issue at some length during the ftf today.

After discussion, those present felt that the initial proposition in
the issue description is not really true: the meaning of a strict
not-in-schema wildcard is unusual and unlikely to be widely needed,
but it does have a well-defined meaning: it does not match any element
declared in the schema, and if it does match an element (which will be
one not defined in the schema), either there is an xsi:type on the
element, or the parent will be invalid.

The difference between this and an imaginary wildcard with
processContents="undeclared" is also visible in the interaction with
open content:  if 'e' is declared in the schema, then 

  <xs:any notQName="##defined"/>

does not match an instance of 'e', which means the 'e' may be matched
by the open content particle, whereas

  <xs:any processContents="undeclared"/>

would match an 'e' and prevent it matching the open content particle.

We concluded that the right way to class this bug report is as
'WORKSFORME'.

Michael, please review this decision and its rationale and communicate your
judgement in the usual way.  Thanks.

I think this rationale exposes the severe lack of orthogonality in the design of this construct; but lack of orthogonality is not a bug (and is nothing new to XSD) so I will accept the resolution.