versioning and extensibility

I know the TAG has been defining versioning and extensions.  Definition of the two just to make sure I am on the right page...
1. versioning - versioning the standard
2. extensions - allowing companies to extend the schema for their proprietary stuff, not to be confused with schema extension element.

Questions up from, but please read on for some context after this question....
My basic question is how can extensioing and versioning be built into the schema to handle the new technologies of xml to object and vice-versa?  I have read some of the TAG findings, but they didn't seem to help me here much.  

Context....
More and more languages are creating objects that unmarshal/marshal themselves to/from xml via xsd's(castor, .NET, JAXB, etc).  You don't even have to do xml anymore.  It is great.  It is magically done for you until you find a bug in the library you are using :). Comparing this to languages as many would like to see these two things work well together in the face of versioning and extensibility.......

Extensibility......
I take the example of extensibility of a Java API.  It is very nice.  (Notice this is pretty standard)
Lets say the standard is a Car object with the method setColor(Color c);
I have my own CompanyXCar which is a Car.  My company has an extra feature called setSpeed(int i); so we add.

A user of the standard would have to cast the Car to a CompanyXCar.  When my feature was finally excepted into the standard, the Car interface is changed such that it now has the method setSpeed(int i).  The user of the standard could now go back to using the complete standard without the cast to CompanyXCar.  I find this problem very hard to solve with xsd's.  More and more companies are using JAXB, Castor, and tools in .NET to create objects that unmarshal/marshall themselves to from the XML.  Many low level programmers that are not involved in the xsd standards are looking for this versioning and extensibility and ease of doing xml without having to do xml.

Versioning
This one is easier and was slightly addressed above.  The setSpeed method was added so 1.1 clients don't break and keep working with 1.2 servers.  The only time something breaks is when something is deprecated.  (Unless you are dealing with a standard that has listeners, but I won't go into detail on that as that is a more complicated topic.

Should we possibly have all xsd created standards create non-extensible/non-versioned schemas and run it through some standard XSL that produces the standard versionable/extensible schema???  What is the cleanest way to do this?  Right now I happen to be using a standard that does not work well with what I explain above at all.  Notice this mistake would have been hard to make with a language api.  You almost have to specify that something is non-extensible, where in xsd's you have to remember to make each and every thing extensible instead of having the default be extensibility and forcing the standards body to make certain ones non-extendable.  Is there some kind of standard yet on how to make an xsd extensible/versionable????
thanks for listening, and any comments, questions, are very appreciated,
dean