While Microsoft's developer devision refines the core of LINQ for the Visual Studio 2007 release, work has already begun on the next version feaures. The one most interesting to those looking to support multi-core computer is Parallel LINQ (PLINQ). Joe Duffy's presentation at Declarative Aspects of Multicore Programming (DAMP) workshop gives a good overview of some of background and issues of LINQ and Parallel LINQ.
PLINQ uses the same syntax as LINQ, but is based on the parallel query execution techniques you would find in major database applications like SQL Server and Orcale.
Prior to LINQ, .NET developers had full control over how queries were executed. The downside to having that much control is that even the most basic search procedures required had-rolling loop and evaluation code. LINQ moves all those details down to the compiler level, essentially making them implementation details.
Since Microsoft controls the implementation of LINQ queries, it can redefine them at runtime to use parallel techniques such as partitioning and pipelining without having developers make significant changes their code.
Parallel LINQ isn't a free ticket into the land of multi-cores, there is still a lot of issues to address. The biggest one is that shared memory still has to be considered. Unlike languages designed with parallelism in mind such as T-SQL, the CLR's type system doesn't support the concept of a pure function. Or in other words, the runtime has no way to know if a function is thread-safe, without side effects, or even if it will always return the same value for a given argument.
Without this information, knowing when it is safe to use parellel techniques becomes very hard. There are on-going research projects like Spec# which seek to address this, at this time it is still pretty much wait and see.