For the official orphans problem, you typically want a crate that contains nothing but the official orphan impls. If such a crate can only be used by the root crate, then the user should be able to select just one orphan impl crate for each impl they require, thereby avoiding coherence problems without the need to bless the orphan impl crate.
The problem with this is that it only helps applications/root crates, and it's not clear that the use cases for "official orphans" are unique to applications, or even more common in applications. Plus, this would go against the principle that you should be able to break up any well-factored application into one or more library crates.
For the official orphans problem, you typically want a crate that contains nothing but the official orphan impls. If such a crate can only be used by the root crate, then the user should be able to select just one orphan impl crate for each impl they require, thereby avoiding coherence problems without the need to bless the orphan impl crate.
The problem with this is that it only helps applications/root crates, and it's not clear that the use cases for "official orphans" are unique to applications, or even more common in applications. Plus, this would go against the principle that you should be able to break up any well-factored application into one or more library crates.
Appears to be part of what's proposed in https://internals.rust-lang.org/t/another-proposal-for-overcoming-orphan-impl-limitations/3863 and https://internals.rust-lang.org/t/suppress-coherence-checking-in-binaries/3491?u=ixrec