Two points, neither of them likely to leave you very happy:

1) From the clause numbers you cite, I conclude you're looking at the
original REC, not the second edition [1], which did clean up this
aspect of things somewhat.  However, the changes _don't_ change that
the 'mixed' on the <xs:complex...> of the _derived_ type determines
the mixed of the result.

2) Even were this not to be the case, you can't get what you want,
because extending a content model _always_ results in a sequence of
the old model and the new.  So if the old were e.g.

   (a | b)*

and you extend it with (emph), you get

   ((a | b)* , emph)

which is not what you want anyway.

To achieve what your clients appear to want, you have to go around the
houses in the following way:

mixed.xsd:

 <xs:group name="bits">
  <xs:choice>
   <xs:element ref="a"/>
   <xs:element ref="b"/>
  </xs:choice>
 </xs:group>
 
 <xs:complexType name="mixedBase" mixed="true">
  <xs:group ref="bits" minOccurs="0" maxOccurs="unbounded"/>
 </xs:complexType>

ext.xsd:

 <xs:redefine schemaLocation="mixed.xsd">
  <xs:group name="bits">
   <xs:choice>
    <xs:group ref="bits"/>
    <xs:element ref="emph"/>
   </xs:choice>
  </xs:group>
 </xs:redefine>

ht

[1] http://www.w3.org/TR/xmlschema-1/#declare-type
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@i...
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

From gkholman@C... Sat Feb 05 18:10:39 2005
Received: from lisa.w3.org ([128.3