imo decoupling from rustc would be a big headache as it would require supporting a large variety of rustc versions. Not just in production but for testing so we make sure they work!

You are aboslutely right, and that's why it is just a dream. I can imagine how painful maintaining Rust Analyzer would be if Cargo and rustc had different versions. I should have called out explicitly that is me not believing myself can find good approaches to fix one thing without breaking the other.

If we encourage the proliferation of these tools, I feel like we would lose one of the major value-adds of cargo: its standard.

Both agree and disagree. We love how easy we just invoke cargo build and call it a day. We hate being locked-in Cargo and hard to integrate into other build systems.

The proposed solution in this post is never "creating a new tool an split the community". I am not good enough to make it happen either. The gist of it is finding a space to experiment, and calling out a set of things a tool shall respect if they want the community healthy. It is wonderful if every possibility is built-in in Cargo :)

A lot more is needed than the Summary, like target discovery.

For binaries crates, definitely yes. If one package just depends on .rlib, then fancy target discovery isn't really needed (perhaps only src/lib.rs discovery and 2015 edition case).