To answer question #1: Yes, I absolutely believe in contract first. Defining web service should be no different than defining any other API. You define your interfaces first using the interop standard and then use whatever technology you can find to provide the underlying implementation. If you ever find fragments of your underlying technology bubbling up the contract level, you know you’ve done something wrong.
Therefore I suppose the answer to question #2 is obvious: Yes, I believe it will lead to better interop. If we all design contract first we can be relatively sure that someone, somewhere is writing tools to support standards based development in our favorite language/dev-environment. If you start using your language/dev-environment’s special tools that don’t follow the standards, then interop support becomes an in house problem as you’ll probably need to invest time in researching how other languages/dev-environments may handle your semi-proprietary contract just so that you can support others as they try and develop against it.
As with the previous question, #3’s answer shouldn’t be too hard to figure out: Yes, I fight against VS and parts of the System.Web.Services API everytime I develop a web service. I design my contracts using the built in XML and XML Schema editor’s, but ultimately end up stiching the WSDL file together by hand. As for supporting the latest web service standards, I’m really looking forward to Indigo, but for now nothing beats WSE 2.0.