I have seen simple select statements with 4 or 5 includes result in nearly 5000 line SQL statements when an equivalent hand-written SQL statement is ~15 lines. The performance of these queries along with the readability when debugging makes it an area that I would like to see the EF team focus on improving.

SQL Server and other databases support Unique Constraints on tables. Foreign key constraints are generally based on unique constrains on the principal side, with the Primary Key being only a special case of a unique constraint.
The Entity Framework currently only supports basing referential constraints on primary keys and does not have a notion of a unique constraint. The idea is to have:

• Support for specifying a unique constraint on an Entity
• Support for specifying a foreign key associations that on the principal end specify columns(s) that comprise a unique constraint but are not the primary key,

Like to be able to build a domain model over data in multiple databases. With out having to manage database objects - linked servers, views etc.

Create a IndexAttribute for annotating entities with index hints for the Database.
For Example

[Index(Direction.Ascending)]
string MyProptery{Get;set;}

EF4 full support of XML field

The current implementation of self-tracking entities is error-prone especially when combined with disconnected scenarios, such as, when using WCF services. The reconciliation process with the ObjectStateManager is convoluted and makes it easy to trip up when saving larger aggregates with Self-Tracking Entities. I would like to see more effort put in to improve the Self-Tracking Entities template and to improve how EF and Self-Tracking Entities interact.

Well it has to be in the .NET Framework data types, not sure whether there would be any work to do in EF for this. Meanwhile there should be a provision to include the new data types in the backend. for e.g. Oracle can have it's own user defined types, SQLServer 2008 R2 has HierarchyID datat type which I am not sure to what datatype it would map to at the conceptual level

We should have provision for such types

EF 4.1 doesn't support stored procedures in code-first:

http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4-1-release-candidate-available.aspx

So far a stored procedure cannot be mapped to an entity with complex properties. Well it can be mapped, but the execution fails at runtime. It would be great if we could map stored procedure columns to entity properties.

CTP 5 dropped compiled query support, this is a huge mistake. Please make sure it is there in the final product.

When I do user.Cars.Add() EF load all Cars for that user.
user.Cars.Count() too

The EF team has marked the previous TVF feature suggestion as Completed saying TVF support will be included with .NET 4.5. It had 226 votes at the time. However, this excludes Code First support. Vote for this suggestion to specifically add Code First support for TVFs.

Table lock, update lock ( WITH(UPDLOCK) / FOR UPDATE ).
LockMode something like NHibernate.

Also should support controlling parameter sniffing

http://stackoverflow.com/q/9890699/85196

This is a must for modularity. We already support this feature on our side with schemas (sql server) the only problem is EF does not take namespaces into account.

Allow for simple delete and update operations that do not require multiple round trips to the database. They could be static methods on each Entity. For example:
Cars.Delete(int ID)
or
Cars.Delete(Guid ID)

This would delete a car record with the associated ID if it exists. The code generation template should be smart enough to create the static methods using the correct data type.

For updates you would pass in the ID and a set of named parameters for the fields that need to be updated:

Car.Update(10, {Status="Sold", ModifiedDate=DateTime.Now}

I think people are doing this now using functions or executing SQL