When working with modules, it is a fairly common practice to structure applications are libraries in multiple set of packages - a package containing the publicly exported types by a given module, and another package containing the "implementation types". I find this way of splitting much more natural than dumping everything into the same package and rely on access modifiers to only expose what I want, and, we use this pattern extensively in the Panama API.
And, there's a reason you use this pattern; the design of the modules feature encourages this. Earlier explorations of modularity had module-visibility for classes and members; if that were still the case, you could have a public interface and a module-visible implementation of that class in the same package. But this fine-grained accessibility model was dropped, and modules became groups of packages, some of which are exported and some of which are not. Unless everything is in one package, it's pretty hard to organize your source base into anything other than "public interfaces in one package, module-public encapsulated implementations in another."
