Hi!
The idea is:
Set a module as Internal/Private relative to its application so that its public elements can only be consumed by other modules in the same application.
When an element is set to public in a module it becomes available to be consumed by all other modules (with the exception of some rules that relate to the type of modules).
But sometimes the public elements of a module should only be consumed by other modules in the same application because that module is just a supporting/internal module; its public elements should not be consumed by other modules external to its application.
Being able to set a module as "Internal" or "Private" to its application to achieve the goal above would allow better control on the dependencies, improve on the architecture, and prevent incorrect consumption of public elements.
I give two examples to support this idea:
1) Integration Builder produces per integration two modules: An "IS" module and a "DRV".
To use the integration you should only consume actions from the "IS" module and not from the "DRV" module, even though the "DRV" exposes public actions.
This is even explicitly documented in Integration Builder.
2) The Forge component "Human Readable Change History" contains two modules: an extension AutoEntityDiff and a module DiffEntityDataToText.
Although of the extension AutoEntityDiff exposes public actions they are only meant to be consumed by the module DiffEntityDataToText which in fact implements the intended functionality, but by mistake any developer can consume directly from the extension.
For the possibility of modules being moved from one application to another application, consumer modules would become with outdated dependencies and when republished they would be broken if they consumed public elements from an Internal/Private module that did not belong to its application.
--Tiago Bernardo