The use cases described in the three comment threads mentioned in
the description are as far as I can see all handled by the
negative-wildcard changes and weakened-wildcard changes
introduced in the working draft of 31 August 2006.  Specifically:

(1) The requirement described by Lee Humphries at
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0164.html
appears to have been associated with RQ-9 by mistake.  It has
nothing to do with negative wildcards, and the declaration
described as desirable can be written using existing syntax as

 <xsd:element name="MessageBody"
  xmlns:mb="www.mymessage.com"
  xmlns:err="www.myerror.com">
  <xsd:complexType>
   <xsd:choice>
    <xsd:element ref="mb:SomethingSpecific"/>
    <xsd:element ref="err:SomeError"/>
   </xsd:choice>
  </xsd:complexType>
 </xsd:element>

This does have the inconvenience that schema documents for the mb
and err namespaces must be provided, and that the names in those
namespaces are top-level, not local to the MessageBody element.

(2) The use case described by Judith Slein appears (as the
discussion thread illustrates) to have several possible
solutions.  She illustrates her problem with the following
declarations. The complex type ResourcePool is illegal in XML
Schema 1.0 because it violates the Unique Particle Attribution
rule (the 'ResourcePool' element in the target namespace is
declared substitutable for jdf:Resource, and also matches the
wildcard, so the two particles compete).

 <xsd:element name="ResourcePool" type="jdf:ResourcePool"/>
 <xsd:complexType name="ResourcePool">
  <xsd:complexContent>
   <xsd:extension base="jdf:GenericContent">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
     <xsd:element ref="jdf:Resource"/>
     <!-- Extension resources are allowed.  They must have the
     structure of JDF resources, but JDF doesn't allow the use of
     derived types to define them.  We will use derived types
     anyhow, but to be prepared for non-derived resources from
     3rd parties . . . -->
     <xsd:any namespace="##other" processContents="lax"/>
    </xsd:choice>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

In XML Schema 1.1, as defined in the draft of 31 August 2006,
this content model is no longer illegal, because the particle
competition is between an element particle and a wildcard
particle.

It could, however, also be rewritten with a negative wildcard,
without changing the language accepted:

 <xsd:complexType name="ResourcePool">
  <xsd:complexContent>
   <xsd:extension base="jdf:GenericContent">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
     <xsd:element ref="jdf:Resource"/>
     <xsd:any notNamespace="##targetNamespace 
      http://www.job-definition-format.org" 
      processContents="lax"/>
    </xsd:choice>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

(3) The XSL use case mentioned by James Clark when the issue
first came up was:

  The wildcard facility in XML Schemas doesn't seem to handle the
  case of xsl:stylesheet, which allows specific elements from the
  xsl namespace plus any element whose namespace URI is both not
  XSL and not absent. This seems to me a pretty reasonable thing
  to want to do.

This can now be expressed using a negative wildcard:

  <xsd:any notNamespace="##targetNamespace ##local"
           processContents="lax"/>

Accordingly, I am marking this issue resolved / fixed and sending
email to James Clark, Judith Slein, Lee Humphries, and others who are
indicated as having expressed an interest in this issue to ask them
whether they believe the requirements they expressed have been met.

Anyone who has an interest in use cases involving negative wildcards
is invited to add a comment to this Bugzilla issue indicating whether
they are happy with this resolution of the issue or not.

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. 

For the record: 

In connection with the resolution of this issue, email has been sent to various
people whose comments are mentioned in the description, asking them to 
confirm that the changes made in the spec resolve the issue they raised
(or, if necessary, to say that that is not so).  Mail has been sent to:

  James Clark (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2006JulSep/0074.html)

  Lee Humphries (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2006JulSep/0073.html)

  Judith Slein (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2006JulSep/0075.html)

  Matthew Fuchs (offline)

  Asir Vedamuthu (offline)