Are you sure you understand those consequences? Here are some guarantees that Rust provides right now that this would completely violate:
- Unsafe code can assume that private fields are private, and that nothing outside of this module can mutate those fields in a way that would violate the invariants they uphold. This encapsulation is essential to upholding Rust's basic memory safety guarantees.
- Every possible impl can be contained in only one crate; this means that two valid Rust crates can never be incoherent when combined together. This prevents irrevocable ecosystem splits.
- If the impl were someday added to the crate it actually belongs in, that would be a breaking change for you. There's been a lot of work into making sure that adding impls is not a breaking change.
So you're giving up the guarantees of memory safety, compatibility with other Rust code, and semantic versioning. Any change to the crate you depend on could be a breaking change for you, ranging from compile errors to silent memory errors, and we should definitely make it unsafe to add your crate as a dependency because of the ecosystem split issue.
I definitely get that these rules are frustrating (especially the orphan rules), and people are trying to find a way to make the system more flexible without giving up those important guarantees. But this feature is so risky I don't see how it could be consistent with Rust's philosophy.