[Zope-CMF] how to distribute CMF components?

[seb bacon]

Background: I find the Undo interface of the zope CMF slightly
confusing, and I think my users are even more likely to do so ("what's
this 'manage_edit' thing?").  So I've hacked up a couple of extra
methods in the UndoTool so that it 

  1) only undoes the last action
  2) treats an 'action' as a logically discrete group of transactions
     (e.g. 'adding a page' is an action, consisting of 3 transactions:
     metadata_edit, metadata_edit_form, and invokeFactory)
  3) works out if the next undo is a 'redo' or an 'undo', to make the
     UI more intuitive.
  
This solution only allows the undoing of one action, but I think it
offers my users most of the benefits of 'undo' with less hassle.

Question: How should something like this be distributed?

For starters, I thought I should subclass UndoTool to create a
SingleUndoTool.  But maybe this is the kind of functionality that most
users want, and it should be in the core?  Should I post a feature
request to the collector?  If I make a SingleUndoTool, how can I
maximise its use to other people?  Should it be treated as a product?
If there are to be lots of custom tools, perhaps there should be a
special 'tools download' section on the dogbowl, with generic
instructions on how to install tools.  I can see this happening with
Workflows, for example.  But then there's a further problem: tools can
be uncoupled from the UI, but they don't make much sense without
context.  Perhaps tools should be distributed with example UI code
too?

Just thinking aloud, really.  But if we're to leverage the clean,
loosely coupled design principles of the CMF to share solutions, I
think we should make an effort to standardise how this sharing might
be done.  

What does everyone else think?  Are there too few third party
components to worry about this for now?  Is the CMF likely to change
too quickly for third-party components to have a shelf-life of more
than 2 months?

seb