I've long felt Cargo had a somewhat ad-hoc genesis, and while there has been good "clean up" work since, there has also been a steady stream of new ad-hoc small features that have been trying to put the whole endeavor on a firm foundation a somewhat satisfying task. Similarly, I think the lack of this clean-up work has been led to many different, sometimes contradictory, intuitions about Cargo in the community, making the discussion of new features/directions more difficult as syntax, semantics, pragmatics are all up for debate at once, in one intractable tangle. I've personally felt frustrated trying to discuss Stabilize Cargo's weak-dep-features and namespaced-features. by ehuss · Pull Request #3143 · rust-lang/rfcs · GitHub and Cargo feature migrations by Ericson2314 · Pull Request #3146 · rust-lang/rfcs · GitHub for these reasons, and would like to avoid that!
Just as Rust has adopted MIR in the past, and Chalk in the precedent, to get a better grasp at certain long-standing issues and unlock possibilities, I think Cargo needs some "core languages" to do the same. I'm less concerned about Cargo's implementations actually using them, at least initially, then the design process, and the social process of synchronizing everyone's intuition.
I have tried to start the process with rust-rfcs/0000-cargo-feature-migrations.md at cargo-feature-migrations · Ericson2314/rust-rfcs · GitHub most of that should be "true" whether or not my particular proposal is adopted.