|P is for Practical|
I really really suggest you not use a name like Misc or Utility. It is most likely mis-named.
I have a module that is nothing but a miscellaneous collection of little subroutines that have nothing in common other that I find them handy. (E.g. my collection includes a sub for stripping leading and trailing whitespace from a string, one for producing a standard timestamp string, a wrapper for CORE::open that returns the open handle and takes care of the error checking, a function that removes duplicates from a list, preserving order, etc., etc.)Why not put them in libraries called String, Time and List respectively?
(rant to the general populous) The word utility, helper and misc denote very broad or unsually specific. The following is an absurd example to prove the point.
One wouldn't create a package called AllMethods that contains everything under the sun in CPAN. It's unweildy and undirected. What if your Utility package has 100 little utility functions. Then you need to refactor, which can be a huge pain depending on the number of developers and the tools available. Moving concepts around will also be hell. There would be too much shared data.
Neither would one create a package for each method. Requiring a user to use all appropriate packages would be a bear to manipulate data. Dependencies could be quite the nightmare. Removing an entire concept would be hell.
The resolution: do not try to avoid classifying a method into the appropriate package. A package w/ one method is not neccessarily evil as one w/ 100 methods as long as they show relation. Yes, a 1 method package may seem silly, but what happens with your time method when you decide to add another? You have an appropriate place for it now.
But what of misclassifications? One misnamed or misplaced funciton is not too hard to move around as long as due dilligence on not waiting until the works becomes too much.
Please. Don't make a Helper/Utility/Misc package. It leads to messy code or less convenient code. (/rant)