Well as we have been writing the WPF/Silverlight versions we have implemented a next generation object model that is completely extensible and has a number of advanced features we don't offer in WinForms. As we convert feature areas over from WinForms we don't just clone them, we look for ways to improve the design and add new capabilities. For instance our completion lists in WPF are much more powerful than in WinForms. But since we are in some areas doing large redesigns and adding features, it does take longer than just copying code.
Per our blog posts, we have already started the .NET Languages Add-on and it is currently our top new-development priority. We have a new innovative parser framework in WPF/Silverlight and we're rewriting the C#/VB parsers to use that. It provides much better support for features like syntax error reporting. See this post for instance:
Our first phase of the add-on will be complete with the release of the first 2011.1 version. That will provide full C#/VB parsing, AST construction, syntax error reporting, and automatic outlining.
After that, the next phase is to start to build ways to get contextual information about what is at an offset (what type/members contains it, etc.). This sort of information allows us to then add automated IntelliPrompt features.
Anyhow, back onto your original question on fragment editing. Can you provide more details on what you do with that in C#? Do you just need the fragments to achieve automated IntelliPrompt (like if you are only editing within a method, etc.? Or do you also require the complete resulting AST to be available when editing other files as well, so that IntelliPrompt can work on the header/document/footer content together from other editor instances?