We had looked into updating things in the WinForms add-on to support lambdas better however found that we needed some major internal redesigns to properly support it.
What we've been doing in the WPF/Silverlight SyntaxEditor codebase is completely rewriting the .NET Languages Add-on from scratch using a new resolver design that is much more flexible and has extensibility points everywhere. The main goal of this was to address some shortcomings in internal design of the WinForms add-on, and follow the C#/VB specs as closely as possible for everything. We've spent a lot of time over the past year or two on the WPF/Silverlight rewrite of the add-on, truly making a solid foundation for all future development.
The latest builds already have better type/member resolution capabilities than the WinForms add-on. In the most recent code (ready for next build but not released yet), we have code to have IntelliPrompt on lambda expression and anonymous method expression parameters. The lambda expression parameters even resolve their implicit types in some scenarios. There are still a couple cases that need work (like where lambdas are passed as arguments to methods) to resolve the implicit type but we need to get a couple more resolver features in place before we can get those working. Even so, they will show up in the quick info and completion lists with the new updates, but as an object type.
LINQ is another items on our TODO list for the add-on. We may knock out parameter info features for SyntaxEditor and the add-on, along with several other new core SyntaxEditor features before doing more with the .NET add-on resolver. But at least our new resolver design has extensibility points for where to plug in future code for LINQ resolution.
Our long term plan once the WPF SyntaxEditor has all the feature areas that the WinForms version does, is to port back all our new designs to WinForms since they new designs are much better overall and have many new features and capabilities we didn't have before.