In general, I tend to organize by responsibility/function. But it totally depends on your concrete project, and architecture, and there is no single definite answer/guideline here. Not to mention that personal taste also plays a large role here.
My suggestion: Look how other people/organizations are doing it. Take advantage of Open Source. Look for Java projects on github, for example, and browse their source. You'll get a feel for different approaches, and can decide which ones you like.
The concept of a module is different from the instantiation of that concept.
Java has always had modules. A method is a module, so is a class and so is a package. A module is a unit of organisation in which internal details are hidden, and that communicates with other modules via agreed contracts. For example, a method is a module because it has hidden internals (the code and local variables) and a contract (the parameters and return type). Modules can be composed out of lower-level modules, e.g. classes contain methods.
What's missing in core Java (pre-9) is a deployable module. All the above kinds of module are not deployable units that can be copied around. Java does have a deployable artifact called a JAR file, but these are not modules because they have no encapsulation or contract: at runtime JAR files disappear, all merging together into a single "classpath".
OSGi addressed the lack of deployable modules in 1998 with the concept of a "bundle". These are physically JAR files and they contain packages, but OSGi defines additional metadata along with a runtime system to support encapsulation and contracts at that level.
Java 9 addresses the lack of deployable modules in a similar way to OSGi. Arguably this was completely unnecessary because OSGi exists and works, but that's a whole different discussion...
Unfortunately Java 9 muddies the waters by naming the new module concept just a "module". This does not mean that methods, classes and packages stop being modules! A J9 "module" is just another instantiation of the module concept. Like OSGi bundles, J9 modules are made out of packages and they are physical artifacts (usually JAR files again) that can be copied around. The runtime system understands and reifies them.
Summary: yes J9 modules and packages are semantically separate notions. Obviously Java has to retain its existing package concept for backwards compatibility. Note that the word "package" is used quite differently in Java than in other languages or in package management systems like RPM. The new J9 modules (and OSGi bundles) are much more like packages in RPM than Java packages ever were.
Best Answer
Java requires that the name of a class file reflects the class name but there's no such requirement for packages. Packages are just names that do not form hierarchies although it might appear so on the surface. It is still a good practice to separate different packages to different directories that reflect the package name. All development environment do this for you automatically.