It may semantically belong to subpackage but still needs to be
available to package1, something not uncommon in templated code
(subpackage is generic implementation, package1 is
specialization that still needs access to non-public functions).

If generic implementation is designed to be customized, it
probably means, it should be widely available for customization,
like xml document and base64 encoder. Also it's probably a
logical error if base type is less visible than the derived type.

What you propose is effectively prohibiting to use packages to
organize your code and requiring to design your module
hierarchy based on desired protection relations, not other way
around. I think it is conceptually wrong approach and
unnecessarily restrictive compared to overall D design
principles (no single "true" way of doing things)

It's ok for packages to exchange public interface, but internals?
If a subpackage has internals, they are for its usage, and
consumable functionality should be provided through public
interface.