Consumer based contracts

I recently listened on a arcast with Martin Fowler and Ian Robinson about some new architecture patterns emerging from the current status of works.
The main point I noticed is consumer based contracts, which is different from the current interfaces in .NET or the WSDL in webservices because this is an example of a provider based contract. The contracts defined by the provider are not often the best choice for the consumer.
I fully agree with the explanation because many times I wanted to add a tiny little field to an interface and didn't want to recompile/redeploy all the servers and clients...
Of course this means throwing away strong type classes with serialization/deserialization because this bounds the runtime to a speciffic XML structure. Unless the serialization does not take into account this new feature. Could LINQ help on this issue, I think yes. Let's suppose I change the interface on the provider to add a new field, and then change only one sspeciffic client to use that field, using LINQ queries. It should do the trick.
As Martin said, working with XML documents adds a lot of delay because of serialization/deserialization, but we should take into account the need for instrumentation which comes into discussion more and more often.
If this will be the future, should we expect a set of instructions in the processor for working with XML/XPATH/XQuery instructions ? A new set of MMX ?