The EF designer only allows you to edit the model, not the store. This means the EF designer only contains 50% of the functionality required to actually do model-first development. Without being able to add tables, views, stored procedures, and constraints there is nothing to map your entity properties to.

The only alternative way is to "Update model from database...", but it forces you to create entities for the tables you import, when all you really want is for you tables to be listed in your store and available to be mapped to. Furthermore, if a table in the DB changes there is no way to edit the store table definition to match.

I supposed that eager loading currently supports only single fixed strategy and except some rare cases this strategy always joins all eager loaded data to one huge record set - at least that is what I saw so far.

I described the impact of such eager loading on Stack Overflow: http://stackoverflow.com/q/5521749/413501

It would be nice to have some control over the way how eager loading is executed with possibility to define if eager loaded data should be joined into single result set with the main data or if they should be executed in separate query.

Something like:

var data = context.Items
.Include(p => p.ParentItem, EagerLoadingStrategy.JoinQuery)
.Include(p => p.SubItems, EagerLoadingStrategy.SeparateQuery);
.Where(p => p.Id == 123);

Generated SQL executed in single roundtrip (the main difference between using separate LINQ queries) will look like:

/* Base item query with joined parent */
SELECT i.Id AS ...,
i.ParentId AS ...,
i.Name AS ...,
p.ParentId AS ...,
p.Name AS ...,
FROM Items AS i
LEFT JOIN Items AS p ON i.ParentId = p.Id
WHERE i.Id = 123

/* Separate query for children */
SELECT c.Id AS ...,
c.ParentId AS ...,
c.Name AS ...
FROM Items
WHERE c.ParentId = 123

It would be also nice to be able to set default strategy globally per context instance.

At the moment I'm not sure if there is another useful strategy for the eager loading but perhaps a community will find another.

It's unfortunate not to be able to mark interfaces for EF mapping (code first). This will allow to really abstract the implementation. Allows a unique representation of the data in the context of RIA Services (if Ria Services allows also for interface 'mapping'). This won't be very hard to implement since EF is happy when it subclasses... For the benefits: imagine you have only interfaces to declare your model. On the server side, you use EF to get your interfaces 'filled' from DB. on the client side you get those same interfaces filled by RIA services... You can reuse any algorithm against your data.
I am not sure this idea will be implemented one day. If it is then I have many other ideas to enhance its usage...

Some times, depending on how you design your model, you want a certain navigation property to be loaded *always*. It's static part of the model just like the (implicit) lazy load nature of a virtual navigation property when lazy loading is configured.

There should be a way to define eager load for navigation properties, something like:

[Include]
public ICollection<Item> Items { get; set; }

and/or via DbModelBuilder:

modelBuilder.Entity<Order>().Property(x => x.Items).Include();

This would greatly simplify client code as it wouldn't have to include on each query/access, and it would also work with Find(key). This would make it more suitable to DDD-style design of entities (so called aggregate roots).

As per http://social.msdn.microsoft.com/Forums/en/adodotnetentityframework/thread/e05f6c62-2dbd-4c3f-87f9-c30c184597c5, “Update Model from Database” updates only the data type lengths and nullability, however, it won’t always refresh the CSDL section.

Due to this behavior, every time I update my database schema, I need to delete the .edmx file from my project and re-generate the ADO.NET entity model again from the database. BTW, this also requires a kludge to remove the previous ConnectionString from app.config, or else the names of the generated entities are not the same.

I would like Update to work as if I had started from scratch, and not some optimized way I don't even understand. At least add an "Update Model from Database As If It Were From A New Database" option....

A problem encountered when an entity is instantiated using non-ef infrastructure, e.g. ASP.NET MVC model binder mechanism. Such entity is pure poco class without proxy. Updates of relationship of the entity can be only synchronized using manual approach according to MSDN(and proven by experience)
http://msdn.microsoft.com/en-us/library/ee373856.aspx "If you are working with disconnected objects you must manually manage the synchronization."
Manual synchronization is really painful approach and really not a good ORM style solution.
The problem even becomes critical for me in decision to migrate my application to nhibernate due to the fact that nhibernate can do such synchronization without problems http://www.codinginstinct.com/2009/11/nhibernate-feature-saveorupdatecopy.html
Detailed description of the problem:
http://stackoverflow.com/questions/3635071/update-relationships-when-saving-changes-of-ef4-poco-objects