I'd recommend using the same code base from the game render-engine for the editor, so you will always be synched. So I'm guessing the easiest way is to stick with the original language.

I think you could use C++ with some parts being managed ie. garbage collected. I use c++/mfc/stl/win32/gl and that's plenty good for me. MFC can be a pain sometimes to work with but you do have the source code and there is lots of info on the net/msdn. It's my understanding that .net comes with lots of features built in that you would have to do in mfc by hand like colored buttons for example so in that sense .net is probably better windowing api. If I were starting over I would probably use .net api with C++ for maximum flexibility and speed. C# is fully managed and might be slow for real-time feedback editor.

The benifit of (and reason for even having) managed C++ is so that you can import your existing C++ code and have it "just work".

My current project shares actual C++ files between the unmanaged C++ engine and the managed C++ editor. This is the only way to do it, particularly because when you add something to one, it works right away in the other (almost halving the time it takes to program). Don't even think of having seperate but equivelent code in C# and in C++ (or in the editor and the engine, not matter what language).

I am not sure if you could share in the C++ code when using C# to write the editor/Windows Forms stuff itself, but I suspect you can. If this option is available, then I'd take it.

Using Windows Forms/managed C++ is very easy, the code is just somewhat less pretty looking than C# (but practically equivelent).

I'd avoid MFC. I have not had much experiance with it at all, but I'm almost positive that programing with Windows Forms will get your program written faster.