It’s not compatible across crates.
Unfortunately, I’m not sure what the data that you provided actually means. It’s late and I’m tired, so perhaps I’m just missing something obvious that should tell me what the data means or how I can use it to determine that this feature is worth it’s cost.
Note: even if you could prove that this didn’t break any crates on crates.io through a crater run, it could still break code not on crates.io. And at some point that will matter more and more as people continue to use Rust in businesses.
But more importantly, why do you want to change the language? This seems like it would be trivial to write a clippy lint with a warning or even just write a refactoring tool that would add #[no_mangle] for you based on the lint. The issue I have with the proposal is that it’s too far reaching for such a small problem and the obvious first steps (the lint/refactoring tool) haven’t been obviously tried, or there would be mention of the fact that they were tried and deemed insufficient.
And that’s ignoring the fact that this would create issue when teaching FFI, because mangling and calling conventions would have a special case that interact rather than being orthogonal.
Anyways, the most constructive feedback I have is “go write a lint” and let’s see if it gains traction and people use it and turn it on in all their crates. If that happens, you could argue that it’s become a defacto standard in the Rust ecosystem and should be promoted into the compiler and then once it’s on by default in the compiler, you could eventually promote it to an error and then eventually, change the default in 2.0.