2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation says
"The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints"
In the downstream sections however, xsi:schemaLocation is not always a hint, as this could be read to suggest.

4.2 notes
"Note: In the sections below, "schemaLocation" really belongs at layer 3. For convenience, it is documented with the layer 2 mechanisms of import and include, with which it is closely associated."
This is pretty non-sensical, unless you are saying that the existing abstractions are broken/cross layers.

4.2.2 Schema Representation Constraint: Inclusion Constraints and Semantics item  1 has 2 cases, each of which result in a D2.  All the sub-cases of items 2 and 3 depend upon a D2 being created, however item 1 is conditional on the resolution of the schemalocation so it does not always result in a D2.  If the resolution step in item 1 fails, no action or result is specified.  The first sentence AFTER this constraint however does appear to specify a result: "It is not an error for the ·actual value· of the schemaLocation [attribute] to fail to resolve at all, in which case no corresponding inclusion is performed."  It appears "no...is performed" should be "...MUST NOT be performed".  This suggests that the constraint's item 1 should also say that if resolution fails a "null" D2 is created (presumably with an absent namespace and no schema components).  "Schema Representation Constraint: Import Constraints and Semantics" avoids this via the "If D2 exists," in item 3.

4.2.2 requires the schemalocation, but allows it not to resolve.  Contrast the words here with those found in 4.2.4.1 and 4.2.4.2.  4.2.4.1 explicitly says "Note that components to be imported need not be in the form of a ·schema document· and need not in particular be declared in the particular schema document identified by a schemaLocation attribute; the processor is free to access or construct components using means of its own choosing, whether or not a schemaLocation hint is provided."  It is currently ambiguous whether this same statement applies to <include> or whether a stronger one applies to <include>.

Similarly, 4.2.4.2 says "Providing Hints for Schema Document Locations
The ·actual value· of the schemaLocationattribute, if present on an <import> element, gives a hint as to where".  Again, 4.2.2 leaves it unspoken whether the intent is to have the same weak relationship between schemalocation and the referenced schema components, or a stronger one.  I.e. can a processor "ignore" schemalocation, perhaps simply by assuming it never resolves, and then fall back on implementation-dependent sources for the schema components (as is explicitly allowed for import) or is a compliant processor's behavior further restricted for include?

The heading 4.2.4.2 Providing Hints for Schema Document Locations itself could be read to imply a broad general treatment of schemalocation, although it is nested under 4.2.4 (import only).  In this case, changing the heading 
from: "4.2.4.2 Providing Hints for          Schema Document Locations"
to  : "4.2.4.2 Providing Hints for Imported Schema Document Locations"
would help clarify its intended scope.

4.2.4.2 mentions conformance profiles further restricting schemalocation.  Is this specific to import (the context would suggest so) or not (logic would suggest so). "Conformance profiles may further restrict the use of the schemaLocation attribute."

4.2.4.2 "When a schemaLocation attribute is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a ·schema document· containing component(s) in the <import>ed namespace."
Does this same warrant apply to include or not?  The nesting suggests not, logic would suggest otherwise.

Bottom line, there are a lot of inconsistencies in the treatment of schemalocation and it would be very helpful to clarify the intent.  The import section even does a decent job of dancing around the layer 2/3 issues.  Maybe it would make sense to factor the bulk of its schemalocation content out, if they really are intended to be (mostly) consistent.