Thanks Arthur for the comments, I must admit I share some of the same concerns and why I really wanted to talk this thru with you folks who are down deep in the code and future of EF before I just start coding away.
First I think I should offer some background. In 2003, just before Linq (and LinqToSql) came out, I and my team created a framework for getting data in and out of a Database which we called Object Data Node (ODN) Library [and yes I'm a trekkie and I was purposefully trying to be able to talk about the ODN Junction and the ODN Relay... Geek Humour]. It was even an early open source CodePlex Project in the first year of CodePlex founding, but I pulled the project when LinqToSql was released.
Anyways what the ODN did was it used Naming convention and CodeSmith (this is also before T4) to allow the creation of a table in the Database and using Codesmith create framework objects that had the same type and name properties as columns in the Database table. It also created a SUID layer that would take Stored Procedure Names for the select, update, insert and delete and allow object retrieval and saving thru Stored procedures. In order to do that as well as mapping output from a sql query to a collection of objects we needed to make the system work the other direction as well. Given an object, map by name and type to the parameters of the Stored Procedure to the properties of the object (including support for Out parameters). If we can map an arbitrary recordset out by column name to a collection objects, it made sense you should be able to do the reverse.
Now to achieve this we used the MS Enterprise Library (3.0) data components to JIT discovery at runtime for the mapping and for the execution of the Stored Procedures and then the EntLib Cache to store mapping information for subsequent calls so you only took the discovery "hit" on first usage, after that we pulled the mapping information out of the cache.
I LOVE the EF and think it has great advantages, but I still am a strong believer in using Stored Procedures for SUID (for tuning, execution planning, separation of concerns, etc). We have stopped using the ODN in all our projects and use the EF exclusively and while we can import stored procedures as functions, we end up using AutoMapper a lot, I'm hoping to help see AutoMapper become less of an issue with this.
I agree that I see some real issues (not just the ones you have denoted) with trying to do this with any raw SQL, and have thought this only really makes sense with Stored Procedures and as such I agree that perhaps SqlQuery is not the best place thing to overload. However the oversight committee had expressed a desire to see this implemented preferably as a overload of SqlQuery, and Hence here is where we are today. I thought I would start there and then we could see where my fork takes us and regroup and decide if maybe we want to do this in a different way.
I hope this makes sense to you, I would be glad to discuss it further if that would help. You can reach me on @matthewhintzen on twitter if you would like to trade direct emails / Skype names / phone numbers