Catching up on the whole discussion, but in response to just the OP – This is definitely an improvement, but ultimately has the same problem as where we’re at now. The author of Ethanol (or Serde, or whatever else) still have to care about every other crate that users might want to use in conjunction with it, and handle it in the same repo.
Ideally I’d like to see a world where an ethanol_serde crate can just exist, independent of either one. I agree that we don’t want to sacrifice coherence in general, but I think this can get solved by a different feature being added to Cargo, which is specifying external vs internal dependencies.
I think that the main issues that could come from losing the orphan rule would come from transitive dependencies conflicting with each other. However, if we were to simply “not leak” orphans that come from an internal dependency, the surface area for conflict becomes your direct dependencies, and their external dependencies (which I think in practice will generally be very small, and mostly limited to things like libc).
I might be in the minority here, but I think it’s fine for two crates to not be useable together as long as that can only occur when you directly try to depend on both. If there’s an ethenol_serde and ethenol_serde2 crate, I think it’s fine for those two to conflict if you put them both in the same Cargo.toml. If we restrict the leakage of internal dependencies, this would mean that both can exist as transitive dependencies and be fine together.