While I generally agree with your post and criteria, there's one that most certainly isn't right:

Looking at the version number is not going to help much. You have to factor in the complexity of the module you're looking at, the experience of the author, etc. Similarly, just because there hasn't been a release in a year, the module isn't necessarily broken. It may just be stable and proven (and I don't mean "biologically stable").

Let me suggest a modified metric:

• Take a very close look at the release history and request tracker of the module as well as the release history of its maintainer.
  • Has the maintainer uploaded any distributions (of this module or another) to CPAN within the past six months? If not, he may be unavailable to fix bugs you might find.
  • Does the author/maintainer typically do many releases of a module or just one or two? Specifically if you're looking at something really ingenious or complicated, there must have been bugs to start with. The quality of maintenance is naturally related to how long it kept the attention of the author.
  • How much time passed on average between a bug report in the request tracker and a reply from the maintainer?
  • If you have questions, check the module documentation for contact info. Only if no explicit contact information can be found in the documentation should you try the mail address of the maintainer's search.cpan.org address.

Do not underestimate the last point. The average quality of support requests for PAR that goes to the mailing list is better than that of those which end up in my inbox regularly. Why? The former at least glanced at the docs. So for many authors, this may be a red herring and you start out on the wrong foot.

Cheers,
Steffen