Should have been that way from the beginning; having the loop variable have function scope was absurd to begin with and forced developers to copy the loop var to a local before using it in a lambda.
Yeah, they could have made the change in C# 3.0. I just don't think anyone really felt the pain until the Task Parallel Library came along in .NET 4. Since the TPL API is lambda heavy people really started using lambdas for asynchronous tasks, which leads (or used to lead, anyway) to pain and misery when using a loop iteration variable.
It could always be worse, though. Look at JavaScript. Simply copying the loop variable in the body of the loop doesn't work because all variables are scoped at the function level. So your "local" loop variable is actually a single instance for the entire function and you have the same exact problem. Instead, you have to actually create another function and immediately execute it with the loop iteration variable as an argument, and then use the parameter within the function to do whatever you wanted to do. Not cool.