Do note that adding impls against the orphan rules does have more technical aspects that need to be solved than simply “accept that my code can stop compiling if dependencies upgrade to new minor versions”.
Realistically, orphaned impls must be made available to the compiler already while a dependency (e.g. one that could write the same impl itself locally, or intermediate ones that depend on such dependency) itself is being checked or built.
This is because when those dependencies are checked, coherence can sometimes apply negative reasoning whose soundness relies on the orphan rules (like “these two impls can’t overlap because one has a trait bound that isn’t fulfilled in the potentially-overlapping case, and it can’t be fulfilled by dependents either due to orphan rules”). And when dependencies are built, code generation can rely on the precise knowledge of whether some concrete type implements some concrete trait (e.g. in specialization – which isn’t stable, but a few standard library features might already be using it – or notably the generation of dyn Trait vtables, where methods with additional trait bounds are only instantiated if those trait bounds are met.)
As a consequence, AFAICT besides the technical challenge of implementing some mechanisms for handling this in the first place, it’s probably hard to avoid a pass of “completely re-compile all (or at least a bunch of) dependencies” whenever you add an orphaned impl. This sounds expensive… so this sounds to me like perhaps those orphaned impls should perhaps better be declared in their own special way and not simply be normal impls in normal code compiled normally except there’s “relaxed orphan rules”.
In fact, such a mechanism might be more fittingly interpreted as just an alternative for – perhaps almost just sugar for – some sort of usage of the [patch] section?