I shouldn't need to decide if an operation's content is going to be serialized in XML or JSON when I'm adding it to the service contract. I should be able to specify this from the endpoint configuration alone.

If you've worked with WCF for any amount of time you've no doubt had to pour through trace files and then try to decipher exactly what timeout setting was causing a particular transaction to fail.

The exceptions thrown by WCF should provide much more concise information- such that it shouldn't be necessary to enable tracing and pour through logfiles to determine the root cause of a particular failure.

I want to segregate my operation contracts into many service contracts. But still want to authenticate user once and allow him to consume other service contracts without asking credentials.

If possible I would like to share some information between service contracts, just like ASP.NET session

A simple way to transition from IDispatchMessageInspector.AfterReceiveRequest directly into BeforeSendReply skipping the actual operation code and instead manually crafting a response message. This is required to handle preflighted POST requests in CORS and other scenarios.
http://blogs.msdn.com/b/carlosfigueira/archive/2012/05/15/implementing-cors-support-in-wcf.aspx
http://social.msdn.microsoft.com/Forums/eu/wcf/thread/55ef7692-25dc-4ece-9dde-9981c417c94a
http://social.msdn.microsoft.com/Forums/nl/wcf/thread/251188b6-87ff-43c8-b6a3-cb77e7aa62e0

Document 'under-the-covers' request-processing workflow when using WCF extesnsions. Eg Gotchas in concurrent request handling scenarios (statics shared across contexts unexpecedly making life miserable for service developers )

Current WCF implementation supports only PasswordText mode from Username token profile 1.0. Provide out-of-the box implementation for PasswordDigest which is very commonly used on other platforms (and was also supported in WSE) and also UsernameToken for key derivation defined in Username in Username token profile 1.1.

Host web client (may be ASP.NET enabled) in standalone application or service near or using WCF.

router services can be expose wsdl for better implementation

At the moment performance of raw IHttpModule as well as Asp.Net web API is way better than webHttpBinding endpoints. Rewriting all WCF stuff is not an option. Real optimization from MS is needed to keep WCF on top.

Sometimes I need to create a custom BindingElement to accomplish some task where the simpler extension points won't be sufficient. It takes an awful-lot of boilerplate code to do this, even when the amount of work I'm trying to achieve is minimal.

When working with web services, to view or modify the SOAP headers requires a whole bunch of work. Why not had a beforeSend event that can be used to dump (or modify) the soap contents. And a afterReceive event that allows me to view the raw SOAP that comes from the server.

I know this can be done, but it takes a ton of code and trying to find any examples that work, have all the necessary details, etc. is incredibly difficult to do.

This is something that is implemented over and over again with different approaches and different combinations of settings. Channel timeouts are good, but the mechanism we use to keep them alive when things are good would be nice if that was an out-of-the-box feature.

It'd be nice if we can describe, in the SOAP interface, that a method's return value is unordered and cannot contain duplicates.

Currently, if a method returns an ISet, it causes SerializationException on the server side when a HashSet is returned, and it causes Add Service Reference to give an "object" typed property.

It would be good to have intermediate interface like

public interface IClientBase : ICommunicationObject
{
ClientCredentials ClientCredentials { get; }
ServiceEndpoint Endpoint { get; }
...
}

and ClientBase<TChannel> definition as

public abstract class ClientBase<TChannel> : IClientBase, IDisposable where TChannel : class

This will allow to write common methods for any client like

void SetupClientCredentials(IClientBase client)
{
client.ClientCredentials.UserName.UserName = someUserName;
client.ClientCredentials.UserName.Password = somePassword;
}

We need a way to build the service which is singleton in cluster with state persistence.