The default assumption, especially for Drupal 6 and up, is that a module exists to do something. Here's a list of modules or functionality I didn't have the time or search prowess to find, however.
http://drupal.org/project/module_filter does some of the grouping and filtering that I want.
customize the admin/build/modules page
create custom groupings of modules in admin/build/modules, overriding the package listing in the individual modules' .info files
the ability to drag & drop modules up or down into groups
and add modules to multiple groups
the ability to drag & drop grups up or down
the ability to hide groups altogether (since Drupal 7 can hide modules individually)
a page would need to list all the hidden modules, in case the site administrator forgets about them
the ability to enable and disable entire groups of modules all at once
example: UI modules like jQuery UI, Context UI, and Views UI that one doesn't need enabled in production but would like to enable all at once to look at the site's configuration
save whether the groups are expanded
search modules within the page base on criteria (i.e. stop relying on browser search on a long modules page)
http://drupal.org/project/moduleinfo proves that modifying the admin/build/modules page can be done
uninstall hooks that tell me what's been deleted from the database
even better, tell me before I press the confirmation button what's going to be deleted from the database
or backs up the database before making any database modifications
maybe individual modules can do this, but Drupal should force it?
ability to get the current module's name
for when I want to do drupal_add_js() or drupal_add_css() and use drupal_get_path() and still have to put the module's name in that last function's parameters
something like:
drupal_get_current_module_path()
that returns the path of where the module's located
why?
in case I want to change the module's name (not likely)
for copy & pasting code and not having to replace the module name from a generic one provided in a example