LINQ to SQL and Entity Model: separated at birth? Part 2

My second question to the ADO/LINQ/C# panel was "Why is there LINQ to Entity Model queries and eSQL queries?". Before I go into the answer, let me introduce eSQL to those that, like I, didn't know about it. First, it is not Embedded SQL. What eSQL is in the Entity Model context, is a very SQL-like query language that you can use to manipulate Entity Model well, eh, entities. Just like the not-so-good old days before LINQ, eSQL queries are stored in strings and should allow you to do most stuff you do in SQL. The big difference is that instead of querying real SQL tables, you query your Entity Model objects.

The answer the panel gave was that, despite the fact that you can dynamically generate LINQ using expression trees, it is a lot easier to generate a SQL-like query in a string, just like we have done for eons with real SQL. So you can use LINQ to Entities for your static, in-code queries, and eSQL for dynamically generated queries. All that sounds good to me.

eSQL aims to have as many of the T-SQL features as possible so we don't feel out of place when generating those complex queries.