Core patches

Please do!

These are both features added by dman.

Currently exceptions to the taxonomy/term/tid path (image module, forum module) to which an "edit-term" tab is added are handled by hard-coded additional menu rules. I am certain this has to be handled better to go in core, and I am fairly certain how to do it but I haven't had a chance yet--

Run an example implementation of hook_term_path for each different module name provided by the {vocabulary} table.

Something like this untested code:

$term = array(
  'tid' => 123456,
);
$result = db_query("SELECT UNIQUE module FROM {vocabulary}");
foreach ($module = db_result($result)) {
  $get_term_path = $module . '_term_path';
  if (function_exists($get_term_path) {
    $path = $get_term_path($term);
    // now the menu item has to replace 123456 with a wildcard /edit-term
  }
}

Actually to work with http://drupal.org/project/term_redirect this would have to be even more complicated, selecting and passing in each different vocabulary ID.

And there are definitely performance concerns with the above that perhaps working in core can be alleviate? But you see how we really have to find some way to hook into the overriding of taxonomy/term/tid that Drupal allows.

^{benjamin, Agaric Design Collective}

Feel free. :-B
Once I'd done it I did take a step back and think "why the hell wasn't this there all along?"
... And I am usually the last one to get keen about adding [my favorite feature] to core. But this just felt so Drupally it was right!

It was actually small and quick, just an afterthought to some other utility I was documenting for a client. What really happened was I was supposed to be writing instructions for how to find, change, add an alias and a menu item for a term. After looking at the steps required, it was easier to fix the process instead of the instructions! Good times.
There's probably a lesson in that.

The real code is quite clean (IMO) and only got a bit clunky later when we added support for additional module paths. The hard-coded rules benjamin mentions. I'd say drop them for core, although there may apparently be a better way.

If it went into core, 2/3 of the module overhead could be done away with (not that there's a lot) although there's still a little of what looks like a copy & paste in there. Only a dozen lines all up tho.
I don't know about the implications to term-redirect, I've not used it. That's S.E.P.

I like your idea of consolidating a few of the mass taxonomy managers. It was frustrating to be helping out a new developer whou'd filled out a badly-structured taxonomy and have to tell them delete and start again because the vocabs needed merging ... or get yet another module. Some of the actions - like moving terms across vocabs - seem to be arbitrarily more difficult than they should be. The existing UI goes out of its way to prevent it and needs a full module to work around that. Possibly for good reason. But in core, that restriction could just be an admin/access-control toggle.

I've also worked on http://drupal.org/project/taxonomy_multi_edit ... although that's about multi tagging more than management, and also needs some UI upgrade.

.dan.

A question is whether taxonomy.module should check for path and menu support, or whether path.module and menu.module should hook_form_alter() the taxonomy term edit page?
I get the feeling that the latter is slightly more pluggable and robust, although the former is slightly tidier for code maintainence.

??
I'm 60:40 in favour of taxonomy.module doing it.
Yeah, it's taxonomies job. Mostly because it makes the layout easier. Lighter code too. OK, I've convinced myself. As you were...