You have to go on the basis of functions, since a modular system based on layers brings very few advantages. Of course, this does not mean that you should completely ignore the (software) layers.
If you think of modules as deployable components (for example, Maven artifacts, JARs-in-EARs), one of the main motives for this is to break the application into pieces that can be turned on and off for specific clients / deployments. In this case, functional modulation is the obvious way.
Even if you are sure that you will not need such a deployment, I would still suggest using modular modularity. Interfaces between functional modules are usually much smaller (and therefore easier to manage) than between layers. In addition, people working on two adjacent layers are usually the same, so forced separation of modules is difficult and often just interferes without any of the benefits that isolation brings.
If you are not thinking about “large layers” (user interface, business logic, database), then this is doable. In this case, I would suggest “modular modulation” (ie both modular and modular), but with functional commands / individual responsibilities with several special roles for hard parts. For example, one designer for the GUI and several programmers, each of whom works with separate functional modules, including the GUI.
Regarding question 3: try breaking these two modules even more. They are usually too rude. If they do not appear after some reflection / discussion, you should artificially separate them to avoid roundness. If not, especially. if you end up with really tiny modules, merge them together into one module. Just do not try to unite as a first step.