Why LLBLGen Pro v3.0 is better than the regular designer for EF v4.0

As a comment to my blogpost about the 12 minute long video of LLBLGen Pro with Entity Framework v4.0, Burton Roberts asks:

Could you list the advantages of using llblgen pro 3 with Entity Framework versus using EF alone?

Of course! Now, I know these posts are often classified as 'marketing' but so be it.

Why is the LLBLGen Pro v3.0 designer better for Entity Framework v4.0 than the regular Entity Framework designer? Below I'll give an (incomplete) list of features you have at your disposal with LLBLGen Pro v3.0 which you don't have with the EFv4 designer.

• LLBLGen Pro's designer can handle massive models with thousands of entities.
• Single entity, multiple target databases (e.g. an entity can have mappings to a SQL Server table and a MySql table in the same project)
• Grouping of entities in the project: as a visual grouping system (so single output project) or as 1 output project (and thus edmx file / code base) per group.
• Fine-grained reverse-engineering features, for full control over how names are created for fields, navigators, entities and the like: patterns for navigator names, pascal casing of names even if they're uppercased, '_' removal, abbreviation replacement, pluralization/singularization, fragment stripping from fields, tables, views and procs (e.g. 'tbl_', 'pr_', both suffix and prefix), auto-grouping of elements based on schemas.
• Configurable reverse-engineering so you decide what follows what: do model relationships follow FK constraints in the database or not (e.g. when the DB doesn't have FK constraints, and you don't want to lose the manually created relationships). The same goes for unique constraints, primary key fields, field length/precision/scale etc.
• True model-first development: tracking of changes made to the the relational model data in the project, and these changes are exportable as UPDATE DDL SQL scripts, including renames of tables, fields etc.
• Unique constraint support: you can define which fields are unique so a unique constraint is created using model-first techniques
• Model views: you can define multiple visual views on the entire project, including documentation, which help you focus on smaller areas of the project and also make it easier to discuss model details with domain experts
• Productive ways of creating a model from scratch using Quick Model. Quick Model is a text-based DSL coupled with a visual representation which allows the user to very quickly create a model from scratch using text sentences. The elements created are added to the main model, and the feature can be used to specify a model quickly during an interview with a domain expert. The domain expert can then immediately see whether the model is correct or needs adjustment, as it doesn't take extra time to create it. As it's the same model the developers will work with there's no time lost by re-creating from scratch a 'real' model based on a report from the interview with the domain expert
• Powerful entity / complex type editing  tools: all fields are displayed in a grid and you can define new fields with all specifics from the keyboard without moving your hands (see the quick model video above). No need to mess with a property grid.
• Automatic forward mapping of fields, entities: auto-map model-first created entities and fields to existing elements or auto-create new tables from the entity definitions
• Fine-grained control over generated relational model data: when using model-first, you generate tables from entity + mapping data. To make this as easy as possible, you want to define whether you want 'CustomerId' be generated as 'CustomerId', 'CUSTOMERID', or 'CUSTOMER_ID' (or even 'customerid' or other variants). This is important for case-sensitive databases like oracle and postgresql. Also you'd want to define whether you want natural character string types, currency types over decimals and variable types (e.g. varchar) over fixed length types (e.g. char).
• Powerful search based on C# / VB.NET linq queries: to obtain information about elements in the project, you can define a linq query inside the designer to obtain the information you need, using the projection you need, and even export the information to excel or other program. 
• Automatic relational model management based on mappings: say you have 100 tables in your database, and you use 90 of them in mappings. LLBLGen Pro can warn you about these 10 tables which aren't used, can automatically remove them for you (through an UPDATE DDL SQL script), exclude them from the project (so they're not used in the project but also not removed from the db) without any effort from your side. This also goes for fields, it can automatically remove unused fields from mapped tables if you want (or warn you instead, or be totally silent about this, your choice)
• Attribute definition for elements: no more 'buddy' classes needed. LLBLGen Pro v3 has a 2-step settings system where you can define defaults which are then used for all instances of the type the setting is specified for (e.g. for the type 'entity', setting A, B and C are set), which can then be overruled at the instance level (e.g. the 'Customer' entity). You can use this to specify an attribute for the type 'field' at the project level, which is then available for each field, and generated into the code for that field.
• Task based code generation using powerful templates. You can easily control which code is generated using the task-based code generation, using templates which can be edited inside the designer. The code generated is placed in separate VS.NET projects using normal classes and namespaces, so it looks like code you'd have written yourself.
• Errors produced by validation contain suggestions how to fix them, often with 1-click fixes inside the suggestion. The errors produced by the validation system can have one or more suggestions to fix the error, and each of them has a link you can click which either fixes the error for you or opens the editor for you of the element containing the error so you can directly focus on fixing the error without having to mess with XML files.
• Clever inheritance modeling: not only can the designer automatically find inheritance hierarchies for you, it also cleans up elements no longer needed from subtypes if you make A a subtype of B. For example, A and B share a 1:1 relationship over their PK's. When you make A a subtype of B, this relationship has to go, and A's PK is inherited from B. Also fields in A which have the same name as B's have to go, as that would lead to errors. This is automatically done for you.
• Define Target Per Entity Hierarchy (all entities in the hierarchy are mapped onto the same table) discriminator field values in the designer and use them in model-first scenarios.

I'm sure I've forgotten things, as well as not pointed out extra features the designer offers on top of the target framework, like typed lists, fields mapped onto related fields and the like.

LLBLGen Pro v3 is scheduled to be released at the end of May 2010.