I wonder (speaking only for myself here, the WG has not yet had a
chance to discuss this issue) whether the situation would be improved
by adding a note to the spec, making clearer why the user option is
recommended and describing at least generally the situations in which
one might prefer to instruct the processor to follow, or to refrain
from following, schemaLocation hints.

Concrete proposal: in
http://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/#schema-loc
the second paragraph of item 3 reads:

    Processors may attempt to dereference each schema document
    location URI in the ·actual value· of such xsi:schemaLocation and
    xsi:noNamespaceSchemaLocation [attributes]. Schema processors
    should provide an option to control whether they do so. It is not
    an error for such an attempt to fail, but failure may cause less
    than complete ·assessment· outcomes.

1) After this paragraph, insert the following note:

    NOTE: When systems rely on an input document being
    schema-valid with respect to a particular agreed-upon schema,
    it is important that they be able to have complete control
    over the choice of schema used in assessment and in
    particular that they be able to instruct the processor NOT to
    follow any schemaLocation hints in the input.  Otherwise, the
    input document could circumvent the agreement and the
    consumer's validation of the input, by referring to an
    alternative schema for the same namespaces, which declares
    the input document schema-valid but which does not adhere to
    the prior agreement between the data source and the data
    consumer.

    In other cases the purpose of assessment may be not to enforce a
    prior agreement between data source and consumer, but to annotate
    the input with type definitions and other useful information from
    the PSVI.  In such cases it will often be better to follow the
    schemaLocation hints.

    Users who need to exert control over the choice of schema can
    normally be expected to be aware of the requirement; conversely,
    users unaware of the issue will typically be those who are not
    relying on the use of a particular schema to enforce a specific
    agreement with the data source.  Casual users will often benefit
    from a default behavior of following schemaLocation hints.

    Useful guidance on how to present this and other questions to
    end users may be found in the W3C's User Agent Accessibility
    Guidelines [UAAG 1.0], [UAAG 2.0].

2) Add appropriate references for [UAAG 1.0] and [UAAG 2.0] to the
non-normative references.

If anyone in the WAI PF working group were willing to venture an
opinion on whether such a note would address the concern felt by WAI
on this topic, or use it to explain what else should be done instead
(or in addition), it would be helpful.

But (again speaking for myself) I have come to think that such a note
would be helpful to readers in any case, so I propose we make this
change regardless.

At the 2009-04-10 telcon, the WG ammended the proposal in the previous comment.  The complete proposal as approved follows.  The WG has instructed the editors to go ahead and include the following proposal in the draft since it seems to be a substantive improvement.

The WG wishes to thank WAI PF for it's comments, with a request to let us know as soon as you can that you approve of our resolution.

Concrete proposal: 
in http://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/#schema-loc
the second paragraph of item 3 reads:

    Processors may attempt to dereference each schema document
    location URI in the ·actual value· of such xsi:schemaLocation and
    xsi:noNamespaceSchemaLocation [attributes]. Schema processors
    should provide an option to control whether they do so. It is not
    an error for such an attempt to fail, but failure may cause less
    than complete ·assessment· outcomes.

1) After this paragraph, insert the following note:

    NOTE: Whether schema location information in the document instance 
    should or should not be dereferenced may vary with the purpose in view.

    When systems rely on an input document being
    schema-valid with respect to a particular agreed-upon schema,
    it is important that they be able to have complete control
    over the choice of schema used in assessment and in
    particular that they be able to instruct the processor NOT to
    follow any schemaLocation hints in the input.  Otherwise, the
    input document could circumvent the agreement and the
    consumer's validation of the input, by referring to an
    alternative schema for the same namespaces, which declares
    the input document schema-valid but which does not adhere to
    the prior agreement between the data source and the data
    consumer.

    In other cases the purpose of assessment may be not to enforce a
    prior agreement between data source and consumer, but to annotate
    the input with type definitions and other useful information from
    the PSVI.  In such cases it will often be better to follow the
    schemaLocation hints.

    Users who need to exert control over the choice of schema can
    normally be expected to be aware of the requirement; conversely,
    users unaware of the issue will typically be those who are not
    relying on the use of a particular schema to enforce a specific
    agreement with the data source.  Casual users will often benefit
    from a default behavior of following schemaLocation hints.

    Useful guidance on how to present this and other questions to
    end users may be found in the W3C's User Agent Accessibility
    Guidelines [UAAG 1.0], [UAAG 2.0].

2) Add appropriate references for [UAAG 1.0] and [UAAG 2.0] to the
non-normative references.

FWIW: as a working group member who has in the past had concerns about issues like this, I am completely happy with the proposed resolution.  Thank you.

The change described in comment 2 has been integrated into the status-quo
documents and the WAI PF working group has been informed of the disposition
of this and their other comments in email archived at

  http://www.w3.org/mid/F6DBA530-0B5D-4FF2-9CC4-2C02002694A1@blackmesatech.com

and asked to let us know whether they are content with the disposition or not.

Accordingly, I'm marking this issue RESOLVED / FIXED.