Right now there is work going on to understand FSX file formats and components. I am working on the xml based scenery files (you can see progress - it is called Scenery Desgin Engine (SDE) and the latest build is on my site). Arno is working on the mdl format for FSX.
As Jon says we are still working on parts. But I am also learning C# now, so therefore I decided to start with a slightly smaller tool to get around that first. That tool will be able to read the new FsX MDL format (so what I learned there should still be useful for this project as well).
Currently I am working on EditVoicepack - this is next on the list, so I'll get right add it sometime between tomorrow and the year 2054.
It is also going to be pretty GUI intensive, and right now it's not really possible to program GUI as Microsoft are quite far behind on the development environment to WPF - and using anything else would simply be insane. Probaly it makes most sense to wait for a smart client factory supporting WPF - better let Microsoft do all the boring work, than trying to do it ourselves and still end up with something that take twice as long to do and only support half of what Microsoft provides.
We are all insane. I'm not really sure if we program because we are insane, or if we are insane because we program. The scary part is how people think programming is so modern and advanced an industry while programmers gets more and more frustrated due to the un-developed processes and tools used. Just think about what "Assembly line" means in IT compared to other industries, and you start to realize we have a problem.
My advise is as follows:
1) Simple GUI, need a result fast, short term project or willing to reprogram the GUI later: WinForm
2) Simple GUI, want to learn and willing to spend the time it takes: WPF with current tools
3) Anything else: Wait for better WPF tools, anything else is a waste of time.
I am currently fighting though 2), and it is a hell. Should probably have gone for 3).
Forget about graphics libraries etc:
1) You would be programming for the past, not the future. As we can never keep up with what we would like to do, we have to aim ahead. When we finally get something done, we normally find we are already behind anyway.
2) They separate graphics from controls. That can't be done if you want a decent object model of your GUI.