I don’t really understand this comment, but my best guess is that its misunderstood my post: this feature is not about allowing cycles between crates (which is absolutely impossible), but about the desire to separate something into a crate in order to get that guarantee that it does not have an interwoven dependency on other sections of your project. In other words, its about the desire to leverage properties of the crate dependency relationship to improve your code organization, not changing how crates work.
Your comments about compiler performance also seem to be off the point to me: a crate is the unit compilation. If you can break a section of your code into a sublibrary, you guarantee that you can compile it separately, and avoid recompiling it, from the other parts of your project that depend on it. Similarly, two sublibraries with no dependency relationship can be compiled in parallel. This is the same principle by which you avoid recompiling all of your dependencies today, and by which many of your dependencies can be compiled in parallel already.
Overall, there’s nothing in this proposal that would involve changing how crates work from how they work today, just allowing you to have multiple private library crates inside of a cargo package.