What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it.
sadly I don't think it'll go that way. C++ is a very closed relative of C, the 2 can mix in the same codebase and the boundaries between the 2 become quite blurred.
C++ allowed C "engine" developers to slowly get use to it without throwing away what they had and was working.. they could experiment with a little of C++ flavor here and there without compromising the structure and without feeling unsafe about it,because they knew they could just switch back to C if and when cornered.
The problem with C# is that you can't "inline" C code into it. The boundary between the "native" side and the "managed" side is VERY defined.. devs from one side can't "play" moving stuff here or there.. everything is much more "frozen"... plus you have the marshaling cost to consider every time you want to move something around.
To make C# (or any other language) a viable option to replace C/C++ in the game engine realm you need to create a compiler that can seamlessly include .c, .cpp or .cs files IN THE SAME PROJECT (warning, I said, project, not solution) . The only language that can be fooled to do this is Go, but just because it doesn't really have a concept of "project"... perhaps D can do it? ( I am not sure).
Until then, you'll have a solid and clear division between "system code" and "game code"... and every time something has to move from here to there it's going to be a big decision with lots of implications.. this will basically leave native devs firm in their camp and managed devs firm in their camp.
I have more hopes for a C++ evolving into something more C#-ish (add modules and optional GC and you're there) than the entire world to adopt C# for everything.