It's hard to reconstruct all of the arguments that led to the requirement
that in principle it should be possible to derive any type in three steps
from xsd:anySimpleType:  the first non-primitive ancestor, then one extension
step, then one restriction step.  So I'm diffident about this analysis.

But it seems to me that flavor 3 (reintroduction of unchanged originals
is OK) is not only what the status quo says, but what is most useful to
say.

Given a chain of derivations from some type T, in which restrictions and extensions both occur, it's useful to know that if any attribute A is
optional in type T, with a binding to a specific simple type S, then in
any type T' derived from T in any number of steps, that A may be present
or may be absent, and if present it will always have type S, or a 
restriction of S.  That's guaranteed by 3, and by the formulation of the
actual rule.  It's not guaranteed by 1, which I dislike for that reason.

The constraint (2) actually formulated in the Note (once gone, nothing comes
back -- reminds me of J. K. Rowling's rules about magic and death) amounts
to saying yes, not only will A always have S or a restriction of S if
it's around, but the portions of the type hierarchy where A is allowed
will form a tree, not a forest.  I hate to say of any fact that it's
uninteresting (it seems to suggest a failure of imagination), but this
doesn't seem particularly relevant to any story about types and 
the substitutability of values.  When considering type coercions and
the acceptability of a value, we typically consider two types: the
one expected and the one encountered.  The details of the chain
connecting them (in a name-based system) isn't relevant, only which
invariants are guaranteed to hold between these two types.

I think the correct fix is to revise the Note to say "nothing removed
by a restriction is subsequently added back by an extension with a
conflicting type assignment" or "... in an incompatible way".

Is that plausible?

On 20 October 2006 the WG accepted the suggestion in comment #1 and
agreed to close the issue accordingly.  The note in question has been
modified to say "nothing removed by a restriction is subsequently 
added back by an extension with a conflicting type assignment"; the 
change is now in the status-quo document and will appear in due course
as part of the next published working draft.
 

> "nothing removed by a restriction
> is subsequently added back by an
> extension with a conflicting type
> assignment"; 
At risk of taking time at a valuable point in our process, is there any issue with adding something back in a way that is inconsistent with respect to something other than type?  An in consistent value constraint, perhaps (Base has fixed="a", nth step derivation has fixed="b")?

I haven't researched in detail.  If others who are expert think there's no issue here, then let's move past this very quickly.  I'm just raising it in case anyone with more detailed knowledge than I have says: "oops, right, badly broken"

Thanks.
Noah