I believe there are problems in the spec in explaining what happens when two schema documents each contain xs:override elements referring to the other (or more generically, with any cycles in the xs:override graph, including as a special case a document that attempts to override itself).

Consider test case over023. This contains two documents, which I shall call P (actually over023.xsd) and Q (actually over023a.xsd).

P.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:override schemaLocation="Q.xsd">
    <xs:element name="doc" type="xs:date"/>
  </xs:override>
</xs:schema>

Q

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:override schemaLocation="P.xsd"/>
  <xs:element name="doc">
    <xs:complexType>
       <xs:sequence>
          <xs:element name="para" maxOccurs="unbounded"/>
       </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

If we follow the process described in 4.2.5, starting at P, then

If a schema document P contains an <override> element E pointing to some schema document Q, then schema(P) contains not only the components in immed(P), but also the components in schema(override(E,Q)).

So what is override(E,Q)? I think it is this (call it Q'):

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:override schemaLocation="P.xsd">
    <xs:element name="doc" type="xs:date"/>
   </xs:override>
  <xs:element name="doc" type="xs:date"/>
</xs:schema>

Next step is to evaluate schema(Q'). Because Q' contains an xs:override element, to do this we need to evaluate override(E, P). This produces P', which looks like this:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:override schemaLocation="Q.xsd">
    <xs:element name="doc" type="xs:date"/>
  </xs:override>
</xs:schema>

To determine schema(P') we again need to evaluate override(Q, E), and since neither Q nor E have changed, this will produce a result identical to Q'. So the process as described never terminates.

It's possible that this paragraph was intended to provide a termination condition: "If applying the override transformation specified in Transformation for xs:override (§F.2) to D and E results in a schema document equivalent to D (e.g. when none of the [children] of D, or of any <redefine> and <override> elements in D match any of the [children] of E, except for the [children] of E themselves), then the effect is the same as for a cyclic set of <include> references".

However, it's far from clear what is meant by saying "the effect is the same". The paragraph refers the reader to section 4.2.3 on xs:include, which tells you to evaluate schema(Q), and evaluating schema(Q) when Q contains an xs:override element takes you back to the non-terminating xs:override rules.

Looking beyond the mechanics of the detailed rules, it's hard to see what they are trying to achieve. What is the use case for permitting cyclic xs:overrides? Given the purpose of xs:override, it feels like a logical error, and I can't see why we don't treat it as such.