Dug a little deeper into this. It seems that we introduced the "validly substitutable" concept, taking "block" of the base type into account, which is suitable for certain scenarios. Then we applied it to many other places where type derivation is checked, without carefully examine whether "block" should be honored.

In 3.4.1, the description of {prohibited substitution} = block indicates that it's for 3 purposes:
1. xsi:type
2. substitution group
3. type alternative (new in 1.1, similar to xsi:type)

I searched for "validly substitutable" in the 1.1 draft to see which occurrences are for one of the above 3. The following look suspicious:

* 3.3.6.1 Element Declaration Properties Correct bullet 4

This is the case mentioned in the bug report.

This does not hurt too much, as no valid instance can substitute "head" with an element through "member1", because of "block". The only difference is whether to reject the schema, or reject the instance.

But this is still a behavior change since 1.0.

* 3.4.4.5 Conditional Type Substitutable in Restriction bullet 2.1

This on the surface is related to type alternative, but it actually has more to do with restriction. We want to make sure that the type assigned by a restriction type is a restriction of the type assigned by the base type. Restriction isn't something we intended to govern using "block", so this seems to be an incorrect reference to "validly substitutable".

* 3.4.6.2 Derivation Valid (Extension) bullet 1.6
* 3.4.6.3 Derivation Valid (Restriction, Complex) bullet 4
* 3.4.6.4 Content Type Restricts (Complex Content) bullet 4.5

Similarly, all these 3 references are about type extension/restriction, and don't fall into one of the 3 "block" scenarios. The references to "validly substitutable" (by taking "block" into account) make certain schema valid under 1.0 invalid under 1.1. e.g.

  <xsd:complexType name="Type" block="restriction"/>

  <xsd:complexType name="derivedFromType">
      <xsd:complexContent>
          <xsd:restriction base="Type"/>
      </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name="base">
    <xsd:sequence>
      <xsd:element name="e" type="Type"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="restriction">
      <xsd:complexContent>
          <xsd:restriction base="base">
            <xsd:sequence>
              <xsd:element name="e" type="derivedFromType"/>
            </xsd:sequence>
          </xsd:restriction>
      </xsd:complexContent>
  </xsd:complexType>

In 1.0, "restriction" is a valid restriction of "base", but in 1.1, because "Type" blocks restriction, "e" in "restriction" can't restrict "e" in "base", and "restriction" becomes invalid.


I think we should update the above 5 links to check type derivation *without* involving "block" of the base type.

The WG decided to add a statement deprecating the use of block, and making that statement a priority feedback item.

The WG haggled over this issue again, and declaring "block" in general as a feature at risk deemed too broad.

The WG began to converge on the possibility of adding the designation of "feature at risk" to the use of "block" in substitution group validity (new in 1.1).  

Details:
(from the IRC log)...
<ht> http://www.w3.org/TR/xmlschema11-1/#key-val-sub-type
<ht> SG: Definitions A, B and C refer to this definition, it didn't refer to 'block' in 1.0, it does now -- that change is the feature at risk"
<ht> SG: "Definitions A, B and C refer to this definition, it didn't refer to 'block' in 1.0, it does now -- that change is the feature at risk"
<ht> The crucial bit is "T. {prohibited substitutions}" in the first bullet

Sandy suggests -- 

Update 3.4.1 where {prohibited substitutions} is discussed to say it's *always* used when checking complex type derivation. (We have to update this section, as the current description doesn't agree with the actual usage.)

Then add the priority feedback there:

*** Begin ***

Editorial Note: Priority Feedback Request

In version 1.0 of this specification, {prohibited substitutions} of a complex type is only used when type substitution (xsi:type) or element substitution (substitution groups) appear in the instance document. It has been changed to take effect whenever complex type derivation is checked, including cases beyond type and element substitutions in instance documents. In particular, it affects clause 4 of "Element Declaration Properties Correct" (§3.3.6.1), clause 2.1 of "Conditional Type Substitutable in Restriction" (§3.4.4.5), clause 1.6 of "Derivation Valid (Extension)" (§3.4.6.2), clause 4 of "Derivation Valid (Restriction, Complex)" (§3.4.6.3), and clause 4.5 of "Content Type Restricts (Complex Content)" (§3.4.6.4). Because of the consideration of {prohibited substitutions}, existing schemas may be rendered invalid by the above rules. The XML Schema Working Group solicits input from implementors and users of this specification as to whether this change is desirable and acceptable.

*** End ***

During its 2009-01-23 telecon, the schema WG adopted a proposal to address this issue.

The proposal (along with other changes) can be found at (member-only):
  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090123.html

The change is identical to the proposal given in comment #4.

With this change, the WG believes that the issue raised in this bug report is addressed. I'm marking this RESOLVED and CLOSED accordingly.