EF4 and getting your priorities right
The world is not waiting on EF directly handling spatial data types. You don’t need them.
Just use Lat and Lng columns typed as float, and set up a trigger so that whenever the Lat column is updated the trigger updates the Geography column.
Most data sinks use separate latitude and longitude values, so you have to handle them like this anyway. The trigger keeps the geography column in synch so stored procedures can use spatial indexes.
Sure you can’t use a spatial index directly in a Linq expression, but you couldn’t anyway because that would entail L2E carting all the rows to the client. To avoid this we always end up writing stored procedures and using a web service to call them, and this is where you munge coordinates into the right form for spatial indexing.
So, the absence of spatial types from EF is not now and never has been a problem.
If the EF team wants to do something useful they could figure out the Linq to Entities Guid join problem. For those fortunate enough not to have encountered this bug, L2E doesn’t like comparing Guids with parameters. It can’t figure out how to compare Guid with object, because object uses reference comparison but Guid uses value comparison.
The generated proxy in Silverlight works properly, probably because by the time the data reaches the Silverlight client you’re probably actually using Linq to Objects, which doesn’t manifest the problem.
In my opinion this is a much higher priority. Guids are very frequently used as primary keys, and therefore also as foreign keys. Guid comparison is extremely common, and L2E is completely broken in this very common scenario.