I think this can be handled in a softer way by tooling, eg we already have the excellent ExplicitImports.jl, and once
is solved it will be integrated automatically into a lot of workflows that use Aqua already.
That said, I think that packages which use internals do it on purpose, not accidentally, and most packages which do it make this very explicit.
About the OP: I mostly experience breakages with packages that reach into the internals up to their imaginary elbows, mostly AD. But they are also mostly very good at communicating this, eg if you try Enzyme.jl on the (yet) unsupported versions, you get warnings.
I agree with those who point out that in the long run, the solution is to factor out those internals to public APIs. However, this is usually takes long since API design is difficult, and people want to get it right if it is to be included in the Julia API.
Experience shows that the best compromise may be a “shim” package that is not officially part of Julia, and contains branching codepaths for various versions, while presenting a consistent interface. This allows experimentation with the API (easier to release a 2.0 than to do that for Julia), and once it stabilizes, it can be included in Julia if necessary.