Where C# differs from C++ in this case is that the standard actively seeks out such corner cases and defines them explicitly, whereas the C++ standard often leaves such corner cases in the "undefined behavior" realm. There is very little "undefined behavior" punting in C#.
I'm not sure how significant that difference will be in practice. It's easy to bash C++ for "undefined behaviour" or "implementation-defined behaviour", and to a certain extent it's fair criticism. However, a lot of the interactions are defined.
Unfortunately, they're defined in chapters of the C++ standard containing dozens of pages of dense language lawyerese. Even experts then get them wrong on a fairly frequent basis, and while the underlying idea behind some of the rules makes sense if you think it through deeply, the rules can still be counter-intuitive to a typical programmer who isn't a standards geek.
In other words, it doesn't much matter if the corner cases are defined explicitly, unless you can define them in such a way that they don't catch practising developers out. I have yet to see any large, complicated programming language succeed in doing this.
I've read most of the C# 1.0 and 3.0 specs. I've also read the R6RS Scheme spec and the Python 2 spec. Admittedly, I've only read a smattering of the C++0x spec. But the C# specs have always been very clear and concise compared to just about every other technical spec I've read.
Side note: R6RS is not the acme of good scheme specs, you might want to try e.g. R4-5RS sometime, especially as R6RS adaptation has been ... less than universal (heck, it proscribes a REPL (no kidding, and not by accident); it's really a different language than the Scheme before it, designed by different people).
