There is perhaps always some risk in a summary of changes.  It serves as a summary only if it's kept short and brisk, but if the descriptions are too short they risk being misleading or producing an apparent or real contradiction by passing over in silence (as here) some of the details of the changes.  If, on the other hand, the list of changes covers every change in all its gory detail, it is likely to be as hard to read as the main body of the spec.  

In this case, I suppose Michael is right to suggest the text has shied too vigorously away from the Charybdis of excessive detail, and has steered straight into the arms of the Scylla of inadequate explanation.

On the self-serving theory that I won't be the only member of the WG who must ask "what changes, exactly, gave rise to items 1 and 4 in section G.1.12, and why do they appear to contradict each other?" I'm going to record here my study of the change records and a summary of the changes I think each item is trying to describe.

Item 1 is marked with diff group vm3-1, which is one set of changes made in connection with 'versioning mechanism 3'.  It was adopted, together with a host of other changes, in the face to face meeting of Oct/Nov 2006 in San Jose, California.  The document "XML Schema Working Group Framework for discussion of versioning" at http://www.w3.org/XML/2004/02/xsdv.html describes V-M3 this way:  

    3.3. V-M3 Fallback from xsi:type value to declared element type

    if an xsi:type in the instance names an unavailable type, allow the 
    schema-validity assessor to use the declared type of the element instead. 
    If the element is valid against a type legally derived from the declared type, 
    then either the entire element instance will be valid against the declared 
    type or a proper prefix of it will be valid; make it convenient to tell 
    from the PSVI what prefix of the instance is valid (if any). 

The changes marked as part of diff group vm3-1 (and related diff groups) include these:

- In 3.3.4.3 add Note about what happens when xsi:type fails to resolve or resolves to an unsuitable type definition (one that fails to override the declared type), and where to find the information in the PSVI.  (I.e.:  the declared or selected type is used, and [local type validity] says whether the element is locally valid against the governing type.

- In 3.3.5.2, add a new infoset contribution, [subsequence-valid], which is true iff an element is locally invalid because attributes or elements are present which don't match the content model or attribute declarations of the element declaration, but would have satisfied clause 1 of Element Locally Valid (Complex Type) if those children and attributes had not been present, and otherwise false.

- In 3.3.5.3, add infoset items [expected element declaration], [declared type], and [local element validity].

- In 3.3.5.4, add infoset items [type fallback], [local type validity], and [descendant validity].

The property [type fallback] has values which indicate how the governing type was selected when an xsi:type in the instance fails to resolve successfully:  'declared' if the declared type of the element is used; 'selected' if the governing element declaration has a type table and the selected type is used as a fallback when xsi:type fails to resolve; 'lax' if xs:anyType is used as the fallback type.  

The property [local type validity] indicates whether the element is locally valid against its governing type definition.

The property [descendant validity] indicates whether the descendants and attributes of the element are all valid or not.   (Together with [local type validity]. this allows consumers of the PSVI to figure out, for a given invalid element, whether the problem causing invalidity is at the top level or among the descendants, or both.)

- Added 3.4.5.2 defining infoset contribution for 'match information', which allows consumers of the PSVI to know (among other things) whether elements in the input match element particles or wildcard particles in the relevant content model.  

So much for the summary of changes.  Item 1 in G.1.12 is clearly misleading in referring to lax validation; in fact in the cases that motivated the change, the fallback is most often going to be to the element's declared type.

Item 4 of G.1.12 is marked as referring to diff group b4299, which resolved bug 4299 and was adopted 9 March 2007, with an additional change approved 23 March 2007.  The changes made by this cluster of diff groups include:

- In 3.2.4.1 add a clause to Attribute Locally Valid saying that if the attribute in question is an instance of xsi:type, then its value must resolve to a type definition.  (It was clear, before, that if xsi:type did not resolve to a type definition, something was wrong, but it was not explicitly part of local validity of the attribute.)

- In 3.3.4.4 add clause 4 to Element Locally Valid (Type), saying that an element E without a governing element declaration is locally valid against a type T only if any xsi:type attribute on E resolves to T.  

(Coming back to this cold, this seems a bizarre distortion of the idea of validity against a type; it suggests that an element with an xsi:type attribute can never be valid against any type other than the one specified, which makes a hash of all the usual claims and assumptions about elements valid against a restriction always being valid against the base type.  This is a botch which should be fixed, even if the formal semantics of QT turn out not to be destroyed by it.  Another legacy of our failure as a WG to develop an adequately clear conceptual framework, and of the spec's determination to make all definitions as procedural as can be managed using language which on the surface is declarative.)

- In 3.3.4.6, add clause 5 to the definition of governing type definition, specifying that skipped elements have no governing type definitions.  (The relevance of this to bug 4299 is more easily appreciated if you re-read 4299.)

I agree that the "must be" in item 4 should be recast; I think the "must" probably should be as well.  Instances of xsi:type occur in document instances; document instances can conform to (be valid against) a schema, but we do not define conformance to the XSD spec for document instances, so 'must' is misplaced here.

OK, so much for the changes in the spec that items 1 and 4 were trying to describe briefly without getting mired in detail.

MK writes "It's hard to see how both can be true", but in fact I think both are true, and I don't see what's hard to understand here.  The changes described by item 4 mean that if an xsi:type attribute fails to resolve to a type definition in the schema, then that xsi:type attribute is locally invalid.  The changes described by item 1 specify what type definition governs the element in that case, so that validation can proceed.  

It's true that users and implementors interested only in a boolean top-level result, instead of in the annotated document defined by the XSD spec as the output of assessment, will not see much difference here:  since the xsi:type attribute is invalid, its ancestors will be invalid (unless one of them was laxly assessed instead of being strictly assessed), and the root will be invalid.

Tentatively, I'd propose the following rewordings:

1.  When an xsi:type attribute appears on an element and has a QName as its value, but the QName does not resolve to a known type definition, the element is assigned a 'fallback' governing type for validation; this will be the selected type or the declared type of the element, if available, and xsd:anyType otherwise.  The validation process is now explicitly defined as including the validation of the element and its descendants; processors no longer have the implicit option of skipping the element and its descendants.

4.  The text now specifies that if an element has an xsi:type attribute which does not resolve to a type definition, then the xsi:type attribute is invalid; it also specifies that if an element has an xsi:type attribute, it is not valid against any type other than the one indicated by the xsi:type attribute.

N.B. the material following the semicolon will need to be removed or changed if the WG agrees to my proposal that we revoke that change and impose any necessary constraint in some more principled way. 

Since this comment includes proposed text, I'm marking it needsReview, but it should be noted that the other editors have not reviewed or agreed with the proposed text; they should not be held responsible for it.

The changes proposed at the end of comment 1 have been made and integrated into the status-quo documents at 

  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html
  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.diff-wd.html
  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.diff-1.0.html
  (member-only links)

Accordingly, I'm marking this issue as resolved.

A bug (bug 11764) has also been opened to track the point mentioned in comment 1 about the treatment of local validity when xsi:type does not resolve.

Michael, if you would verify the fix and close or reopen the issue accordingly?
 
Thank you.