In my mind having a good interop support by a web services toolkit is a paradox. Interoperability with every other toolkit in the market would mean supporting new and emerging standards as well as old and aging, pushing for best practices and instustry standards along side with used-to-be-best-practices and proprietary standards.
One example for the last point is Wcf support of clear username and password in the message. Since this is a worse practice to send user/pass on the clear, Wcf did not allow it initially. But if you are a developer instructed to consume a third party which uses exactly that - the last thing you want to hear from your toolkit is "The provided URI scheme is invalid". For this reason I have written ClearUsernameBinding and for the same reason Wcf 4.0 now supports an "insecured transport" mode.
So are we doomed to stay with worse practices just because of interoperability? And will we need forever legacy standards such as DIME or WS-Addressing draft august 2004 just for the sake of backward compatibility? I hope not. So I expect Soap stack vendors (or Rest-stack for the matter) to do a smart phase-out of these standards / practices.
One attempt was back in .net 2.0 days where a web service would have a best practice mode (WSI compliance) and in order to use non WSI stuff you had to explicitly turn off some flag or get a compilation error. This is not good enough - it makes the bad practice too easy. I hope in the next version of Wcf we will not see too many "allow insecure" / "no validation" flags, nor support for sunsetting standards. Instead the SDK should supply detailed and functioning examples on how to extend Wcf to do this. Will it shout to developers "you're doing something bad" if they try to create a new service using these samples more than a "no interop" flag or compilation error? I believe so since developers know they do something wrong when they see too much code to maintain... And these samples will allow interoperability where absolutely required.