You should go feature-based as layer-based modularization brings very little benefits. Of course this doesn't mean that you should completely ignore (software) layers.
If you think about modules as deployable components (say Maven artifacts, JARs-within-EAR), one of the main motives for this is to break up the application into parts one can turn on and off for certain customers / deployments. In this case feature-based modularization is the obvious way to go.
Even if you're sure you won't need that kind of deployment, I'd still suggest going with feature-based modularization. Interfaces between feature modules tend to be much smaller (and thus easier to manage) than between layers. Also, people working on the two adjacent layers are usually the same, so enforcing module separation is hard and often just gets in the way without any benefits the isolation brings.
Unless you're thinking about the "big layers" (UI, business logic, database), in which case it's doable. For this case, I'd suggest "matrix modularization" (i.e. both feature and layer modularization), but with feature-based teams / individual responsibilities with a few specialist roles for the hard parts. For instance, one designer for GUI and several programmers each working separate feature modules, which include GUI.
As for question 3: try breaking down those two modules even more. They're usually too coarse. If they turn out not to be after some thinking / discussion, you should artificially split them just to avoid the circularity. If that feels wrong, esp. if you end with really tiny modules, merge them together into one module. Just don't try merging as the first step.