have a type on the server that is defined by an Enum with a restricted set of values, I want to be able to expose that through my model and through my data service

I have a service operation defined on my service that is exposed via the metadata. When I use the Add Service Reference gesture to create client proxy code, the proxy code should include methods that call those service operations (for instance, if I have a service operation with the signature "IQueryable<Customer> GetCustomerByCity(string city)", I should have a corresponding client method that calls that service operation and materialized the result

Allow me to attribute the model or server side types with validation attributes. Those attributes should then we in the metadata description of the service and code gen'd onto the client types.

When I work with a service those validation attributes should be applied automatically and I should be notified when a validation failure occurs

A lot of the data for my OData serivce comes from my database, but I also have a need to have some of the entities in my service come from another data source (example: an existing web service)

gzip, deflate

Provide support for a third wire format (other than JSON/ATOM) that is a binary format.

To reduce payload, solution simmilar to this one would be handy.

http://blogs.infosupport.com/blogs/alexb/archive/2010/12/21/wcf-data-services-optimizing-updates-in-the-client-library.aspx

It has been discussed here as well: http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataservices/thread/180e583f-81cb-4b89-8aa9-3b1d15ec47bf/

Type inheritance is a "must have" if you want to facilitate the adoption of OData on current object oriented frameworks.

As V3 will fully support Entity Type inheritance, why not extending it also for complex types, as the CSDL Format spec already states?

Now WCF data service supports getting json-formatted response by specifying Accept=application/json header in request only. However, It does not support $format=json as a query option, although it could be circumvented by copying code from http://code.msdn.microsoft.com/DataServicesJSONP and decorating service class with [JSONPSupportBehavior]. The lack of its support is a well-known issue. Hopefully it can be fixed soon and save people hassles of copying extra code and compiling and publishing.

Allow for the mocking / stubbing of the DataServiceCollection and context. All the constructors are internal. It would be nice if they all had interfaces that could be easily stubbed out.

Allow me to add annotations to my OData model (Range, Display Member, etc) and have those be picked up by the client code generator. The annotations should be exposed by the service's metadata endpoint for any client to consume if needed.

If I have a schema that has Orders and OrderDetails, I dont want /OrderDetails to be direclty accessible. I only want it to be readable through its parent: /Orders(1)/OrderDetails. Basically what was discussed on the astoria blog a while ago:
http://blogs.msdn.com/astoriateam/archive/2007/12/21/design-notes-uri-containment-in-astoria.aspx

By looking at the condition of the global economy, I believe there'll be some resistance to upgrade to Office 2010 when it'll be released. oData works great but it only intended to work on Excel 2010 and not Excel 2007. Can Microsoft make the oData consumable by Excel 2007? This will be HUGE for the LOB applications.

make HTTP and output caching easy to setup in WCF Data Services

The WCF DS Client currently does not support batch updates with entities that have the MediaEntry attriute (IsMediaLinkEntry=true). This makes it impossible to have Streams/Blobs/Documents being part of a transaction by using Context.SaveChanges(SaveChangesOptions.Batch).

It would be nice to have this supported out-of-the-box by the WCF DS Client.

The issue has been discussed here: http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataservices/thread/26387eb6-0798-46a2-9010-8ead84b38144

Title says it all

The current use of query and change interceptors is good for simple business logic to filter out results etc, but for more complex business logic you can end up exposing a custom service operation. I would like to see more control over wiring in business logic into data service calls.