LinqKit has shown that is possible to make the creation of queries much more dynamic, with them being composed at run time dependent on external conditions. nHibernate is good at this and LinqKit helps, but it would be nice to have an official solution.

Support for mapping System.IO.Stream to Binary fields

Currently this requires lots of ceremony setting up ILogger infrastructure as described in https://docs.microsoft.com/en-us/ef/core/miscellaneous/logging.

Need a new type of ClassDiagram tool for Code-First POCO classes which should be similar to Entity Designer, capable of showing relationships, keys, db schema related meta data etc.

Similar to adding support for stored procedures in Code First, but for functions also.

Using model first, this is supported and using EdmFunctionAttribute they can be used from LINQ to Entities. I really miss this in the Code First approach.

See also: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions/suggestions/1607971-code-first-support-for-stored-procedures?ref=title

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

See http://www.pabich.eu/blog/archive/2012/05/16/Entity-Framework-migrations-donrsquot-support-parallel-development.aspx

It would be very nice to be able to support properties which are collections of value types. Just to have an array of doubles I shouldn't need to map each value to a class. NHibernate has this feature. E.g.
class Benchmark
{
public long Id {get; set;}
public string Name {get; set;}
public IDictionary<DateTime, double> Returns {get; set;}
public int[] Vector {get; set;} // preserve the order too
}

Support Stored Procedure Return Values, output parameters of any type and procedures that don't return a result set, like an update statement.

Currently, a discriminator column is only possible in TPH scenarios. The rational behind this is that in TPT the entity type can be inferred by joining. This is true but costly. In a serious application with many rows, the existence of a discriminator can have many benefits. For instance: one can create a composite index on the discriminator and primary key, on the base table (I could also use an index on primary key, filtered by the discriminator).

I would like the option to detach an entire loaded object graph easily using the DbContext API. And to attach the graph again with several option for choosing if existing data should be overwritten or not.

We have seen that there are lots of discussion surrounding the generated SQL not being optimized. Entity Framework should have a provision wherein User should be able to change the Generated SQL and use it for further processing through some mechanism

We need an easy way to give the user the "Cancel" functionallity when he make changes to entities data but he does not want to save changes pressing Cancel button. I think adding DiscardChanges to ObjectContext is the solution, going back to its initial state and dissapearing added entities (even child entities) and returning modified or deleted entities to their original state

want to use the entity framework. However I also have the requirement of allowing my users to define custom fields in our system. I would like to still use the entity framework and not use a a partial class with a hash table property.

I would like some API for checking if database schema is correct for edmx storage model.
It could be something like

List<string> errors = new List<string>();
bool isCorrect = context.ValidateDbSchema(errors);

I'd like to see a well designed EF project template that made use of the Repository pattern for abstracting the data access technology. This should showcase best practices for using Code-First and POCO entities, UnitOfWork abstractions, solutions for querying entities that span multiple repositories, etc. This information is pretty hard to come by for EF but available in abundance for other ORMs.

When generating from database, the EDMX designer should generate XML Documentation (Summary field) from the SQL Description field of each table/column etc.

So far a stored procedure can return only a plain entity. It would be great if we could create a stored procedure that returns orders and details information in a single roundtrip.

Now that EF 5 supports enums, please (optionally) create Lookup Tables in the database with the enum items or store them in the metadata.

This enables Lightswitch and other apps to reconstruct the enums/use the Lookup Tables.