To me, the term "module" tends to relate to the notion of "being modular", which gives a sense of being an independent piece that can easily be snapped together with any number of other independent pieces in order to make a vast assortment of different things, or used by itself just to do a particular task.

What you're describing seems different. Your A,B,C and D are not independent: if you need to use any one of them, you end up needing all four. It's not clear what sort of functional or objective specialization (if any) is leading you to make A,B,C and D separate, but if they're as interconnected as you say, maybe they shouldn't be separate.

Having a module depend on one or more others makes sense when the dependency is based on inheritance, or if the object defined in one module is supported by a "helper" or subordinate object in another module (like Archive::Tar, an object for a tar set, uses Archive::Tar::File, an object for an individual data file in the tar set). But a common property of such dependency is that it is unidirectional in some sense.

I'm actually a little puzzled about a design where "A uses D" and "D uses A". Why would these be two separate modules?

You haven't given enough detail, but one guess that comes to mind is that you could do a better job of dividing things up so that dependencies aren't going in all directions: the parts of D that are used by A and C might belong in a fifth module "E", which would then be used by A, C and D; and similarly for the parts of A, B and C that are used by D, etc.

Also, since these are modules, I'm assuming you're envisioning a set of apps that will use them. Is there ever a reason that an app would use D rather A (or vice-versa)?

If you haven't looked at Damian Conway's book Object Oriented Perl, it would probably be worthwhile to check that out.