In general I agree with tlm that the answer lies somewhere between 3 and 4. But I also think you're on to something when you suggest different approaches to core and non-core modules. So at the risk of suggesting an approach #5 ...

With core modules I ask: "What version of Perl am I requiring? Was the module I'm listing as a dependency distributed with Perl in that version? And, if so, did it lack any features at the time it was introduced to core that I now want?"

If the answer to the that last question is yes, then I have to go to that module's Changes file, see when the desired feature was introduced, and explicitly list that in Makefile.PL. If the answer is no, then a simple require [targeted perl version] takes care of the problem.

The answer to the second problem can be approached with Rafaël Garcia-Suarez's Module-CoreList.

The answer to the first problem is to ask, "How backwardly compatible do I want my module to be?" If the code is going up on CPAN for universal use, then you may want considerable backwards compatibility. OTOH, if you're a consultant designing an application for a customer, you can be much more flexible depending on his/her upgradeability potential.

With respect to non-core modules as dependencies, it's much more of a crapshoot. Approach #3 seems very reasonable there. Let CPAN users give you feedback if you're requiring too recent a version, then change it in your next upgrade. (I personally shy away from distributions that sit on a mountain of dependencies, but that's more of a personal taste.)

And, of course, given the distributions you listed as examples, one should ask, "Do I need this module for my module's functionality, or simply to write a better test suite?" But that is for another thread (and has been!).

HTH

Jim Keenan