schema binding proposal : support for conflicting schemas

During Toronto f2f meeting, we discussed this proposal but did not reach a consensus. We decided to continue the discussion over email.

I had raised questions during the f2f meeting about the following 2 scenarios.

[1]
Suppose there are 2 instance documents D1 & D2 corresponding to 2 conflicting versions of a schema. If there is a reference R from D1 to D2 and if R has a targetType/Element constraint on it, how do we enforce the constraint if the type/element involved in the constraint has a conflicting definition? How do we determine if the types/elements are equal? What does type equality mean across 2 conflicting schemas?

[2]
How would one enforce an identity constraint if its definition conflicts between the 2 schemas? That is, for example, one identity constraint defines 2 fields and the other defines 3 fields. How would one compute and compare key-sequences?

We could come up with more cases like this. May be we should enumerate them all and address them one by one.

However, I would like to take a step back, better understand the underlying scenarios and weigh them against the added complexity.

I completely agree with the intent of schema binding proposal. It aims to make interop more deterministic which is the right thing to do. I believe, much of the complexity in this proposal is the result of the desire to support conflicting schemas. If that aspect is removed, the proposal becomes straightforward. In my opinion, this would be a good thing to do in the first version of SML spec.