Well these are the 3 major goals for SE next:
1) Support more platforms since SyntaxEditor is our flagship product. Platforms supported hopefully will be WinForms, WPF, Silverlight (looking into it) for editing, ASP.NET (CodeHighlighter), and a Windows Live Writer blog plugin for syntax highlighting (possibly).
2) Make all of those platforms use an improved document/parsing library assembly that has the same code regardless of platform. This assembly will likely be .NET 2.0-based so that it can support people still using .NET 2.0 only for WinForms and/or ASP.NET.
3) Improve the language building and maintenance capabiltities, meaning make possibly a standalone application that uses wizard steps to walk you through easily creating a language, then an IDE for maintaining it after that. And this would be for making the language lexical, semantic, and maybe even other features.
So the WPF platform implementation is just a part of the entire goal. Specific to WPF, everything Kelly said is spot on. While SE for WinForms works fine in WPF, it's not usable in docking window UI's since it will show on top of the WPF auto-hide flyouts, etc. It's certainly easier to do some neat effects with WPF, although the core text rendering is more difficult. WPF certainly is going to be the future... Microsoft wrote their core Expression tools in WPF, and is in the process of converting all of VS over to WPF in the coming years.
Additionally we get a lot of requests for a WPF native control and since we are a software company, we have to create products that people want. Since SyntaxEditor is our flagship product, it should support as many platforms as possible. Plus it would be really cool if we could have a Silverlight variation, based on at least a subset of the WPF variation. Imagine making Silverlight applications with a syntax highlighting editor. That could be very popular in itself.
Anyhow, again that is just a part of the design goals. The other things will affect and improve WinForms as well.
Back on topic... :)
I did some quick testing. It appears that only the active view is doing any sort of selection tracking for undo. Can you confirm that?
If that is the case, what if the modification tracked a Source property and maybe a SourceData property. The Source could be some kind of reference or id for the View and the SourceData could be some arbitrary data, like a TextRange indicating the selection. Then when an undo occurred, each view could look at the modification, see if the source is the view, then restore the proper selection if it is.
1) We could just keep some static Int16-based number that incremented and rolled over when maxed out. Each view when created would store the next value. That could be used to identify the view, even though not guaranteed to be unique. However for these purposes, it doesn't matter too much if two views end up with the same ID. Maybe even a byte would be sufficient. Just trying to think of how to best store info for this feature with minimal memory.
2) Source could be a WeakReference to the view. This uses more memory but is the completely correct way.
3) SourceData could be a TextRange, or maybe instead we just store so bit flags. Like one for no selection. One for normalized selection and one for reversed selection. Really, aren't those the only three things that can happen? No wait... doing some testing in VS. If you highlight a word then do comment line, then undo, it restores the original selection. So does look like TextRange is needed.
For the caret navigation now... another thing is notice in the VS TextEditor options there is an option to include caret movements in the undo list. That's interesting but also seems to be separate from the other tracking.
For instance, if that option is on, I can undo and it goes through the list of places i either last made or removed a selection.
The Ctrl+- ignores that and doesn't seem tied to it at all. Have any logic ideas on what needs to be done to get the Ctrl+- working? How does it seem like MS tracks this internally? Looks like they are storing a text blurb with each location too. I could see text in their context menus which was next to that location in the document that I had later deleted.