That being said...Scott Hanselman calls it WS-Death Star for a reason. (WS-*, heh. Nerd Jokes. Check.) Hopefully this kick starts the same kind of rapid evolution that Asp.net MVC had after it was open sourced.
I very much doubt that. WCF is one of the most over-engineered frameworks I've encountered so far, and I've seen many. It's an epitome of enterprisiness, with every miniscule detail configurable via XML, with countless layers of abstractions, factories and providers, with very specific modalities, with all kinds of pluggable serializers, with metric ton of other crap. Because WS-*.
So it's very unlikely that some average developer will go spelunking through the codebase to fix some obscure bug that occurs when interoperating with an Apache Axis-based Java web service that is using WS-ReliableMessaging with WS-Addressing over carrier pidgeons. Not gonna happen.
While WCF supports WS-* and is in large part organized around it, some of the complexity isn't "because WS-", its "because WCF is a higher-level abstraction that supports, among other things, WS-* ".
I mean, you can apply all that overengineered configuration to build REST services with WCF, too. You probably don't want to (unless you are already heavily invested in WCF), but you can.
And it fails spectacularly. I mean, _it works_, but it's a disaster to work with and write software against.
The entire abstraction is leaking profusely, all precisely "because WS-*". Who in their right mind will attempt to establish a family of standards for "transport-agnostic" communication, routing, serialization and whatnot when realistically 99% of the time HTTPS is all you ever need?
Can you give an example of how it's a disaster? I'm genuinely curious because I've had to use it for at least 5 years (I still support 1 WCF solution) and this was never my experience.
This may be true to an extent, but rarely will you ever need to delve into that level of minutiae (which itself is a consequence of WS-*...). I've set up custom endpoints, but that's comparable to setting up custom logging with Log4J. I've extended/written custom Message Inspectors to log/analyze/manipulate data, but that was hardly complex as well, and comparable to what you would need to do in any other environment but without support of the framework.
For me the most frustrating thing working with WCF was probably correctly configuring Windows authentication/authorization simply because there are so many different ways things can fail with similar error messages. Everything else you mentioned is stuff that you rarely need to consider.
I know what you mean, though. I have this one web service that's the bane of my existence. No WSDL, it's WS-Transfer and MEX and WS-Sec with it's own STS...makes me weep thinking about it.
Conventions are supported as well, but is woefully underused.
That said, WCF is a beast. If you need SOAP with federated security and bells and whistles, it is a very solid choice.
If you can make it through with REST you should avoid WCF. It is a time sink.
It will either be a godawful Fluent API on top of all the WCF craziness, or the conventions will be as unusable as they are in Entity Framework.
Old-style ASMX services were cool. Nothing fancy, no infinitely configurable doodads: just a single class annotated with attributes.
A lot of the complexity is baked into the WS standards of which WCF is only an implementation. So until new standards are rolled out there is a limit to how much clean up can happen.
Then the other thing is the fundamental concept of WCF requires a lot of inherent complexity.
There is still a good amount of complex for complex's sake that could be cleaned up so hopefully that happens.
But its been said WCF is pretty much dead so not sure how much effort will go into it.
I know REST/JSON is the new hotness, but there is a bunch of that stuff out there.