I don’t see how you can draw this conclusion. Taking C++ and breaking backward comparability just means you can move the standard for C++ foreword without concern for supporting 10+ year old source code. I cannot see a reason this would impose some stringent, immutable by default ownership/borrowing requirement, a radically different type system, a lose of template meta programming for macros (in the case of Rust) or the adding of garbage collection and an invasive runtime with a language imposed concurrency model to the exclusion of others (in the case of Go).
Sure as time passed, the non backward compatible C++ would add features not currently in scope for C++, but the radical redesign of the fundamental language is not what this proposal suggests.
Those two languages were created without consideration of backwards compatibility with C/C++ source code and were designed for the same job. It stands to reason that given no constraints of compatibility, you'd get something similar to those languages.
Now obviously, those languages do not have all the features of C++ nor the same design principles. But as soon as you have all the features of C++ with the same principles, you have something so close to C++, that it doesn't make sense to break backwards compatibility.
