One of the things that people (like Stefan and Jacek) seem to have picked up on in SSDL is the fact you can describe headers. This was a source of debate within the SSDL author group too. The general thinking was that the header feature won't often be used, deferring the declaration of headers to any attached policies. However, there may be occasions where I, as a protocol designer, absolutely want to put a header in one (or more) of my protocol's messages - this isn't a big deal at all and in fact is a strength of SSDL - you can use it to describe SOAP messages, not just the content of the soap:Body.
Stefan suggests that SSDL might be a WSDL replacement - it isn't. We're not interested in playing the standards game, nor would we be taken seriously in it. SSDL is the result of a group of people coming together for a "what if?" kind of project, where in this case the "what if?" was contextualised by the thinking behind MEST and an interest in seeing if descriptions could be more useful. As for referencing WSDL, that was a concious decision too - we thought it would help to place SSDL in the right context, and the MEP plugin was there to show how SSDL could be used as a direct replacement for WSDL in certain constrained (SOAP-specific) circumstances. (BTW thanks to Amy Lewis and others for feeding back on the bugs in our MEP document)
Stefan also asks about multi-party interactions. The SC protocol plugin is desgined to support true multiparty interactions. Simon Woodman is an expert in this area and lead the development of that plugin based on the research work he does at Newcastle University's School of Computing Science. I'll defer to Simon's greater depth of knowledge in the area...
As for dropping WSDL's "interface" and "operation" names, well that's just commonsense when you're talking about transferring messages not invoking *cough* objects :-)