You have nothing to gain by making separate installations unless you intend to use these modules in separate places.

Hmm. I sometimes develop in this way. You do get some useful things from this model:

• You can easily separate the test scripts that apply to this particular module from those that apply to another. This allows you to easily run only the relevant tests when testing a module. This can save time and make TDD considerably more pleasant.
• People can work on modules independently from each other.
• It can give you a nice clear separation of unit tests (distributed with module directory) and acceptance tests (distributed with application as a whole).
• Allows you to easily release module updates rather than application updates as appropriate.

There are certainly other ways of getting these benefits, but the CPAN-ish structure gets you a lot without any effort.

I think you can do all of these things just by making separate test scripts for each module and only running the one that pertains to the module you're working on. That's what I'm doing now.

Having a single test script per module is not always practical.

Also I find having people work independently is harder if you keep everything bundled together. With separate distributions you can check individual modules in and out, only update single modules, avoid name clashes with test scripts from other modules, document prerequisites on a module-by-module basis, etc.

There are certainly other ways of getting the same sort of functionality - but I don't see that having multiple module directories has any major disadvantages.

The advantages I see of moving groups of module files (*.pm) into module distributions are that tests would be bundled with the code they are testing, support libraries needed just during testing would be bundled in as well, and in many cases, only one or two module distributions would be required for standalone development and unit testing. It seems to me that it would be easier to have someone work on and test just one module distribution without having to understand the entire design and interactions between it and other modules.

It may well be that these advantages are outweighed by the disadvantages -- that is part of the assessement I'm currently trying to make before going very far down this path. Some disadvantages of this bundling into module distributions are that later code restructuring will become more difficult, and that additional work is needed at the very least, to setup the framework for doing module installations.

The advantages I see of moving groups of module files (*.pm) into module distributions are that tests would be bundled with the code they are testing

If you have a single big bundle, the tests are still bundled with the code they are testing.

support libraries needed just during testing would be bundled in as well

I don't see why these couldn't be part of your big bundle as well.

in many cases, only one or two module distributions would be required for standalone development and unit testing.

Does it hurt anything to have the other modules there if they aren't being used?

It seems to me that it would be easier to have someone work on and test just one module distribution without having to understand the entire design and interactions between it and other modules.

Why is this difficult to do when they're all together? I have lots of modules as part of one project with no separate installs. Each one has a separate test script. The tested modules don't interact with each other at all during tests unless it's really necessary. While working on one module, I just run that module's test. When I'm ready for integration testing, I run all the tests. If you split up your modules, integration testing will be a lot more hassle.

You can split them up if you want to, but I just don't think you'll get much value from it, unless you plan to release individual pieces to CPAN.