>>I wrote:
>>> 1.  Does Monticello offer some help with this situation?
>>> 2a.  Do I go ahead and just directly modify the existing class method
>>> to add my two lines and mark it as a Monticello class extension, or
>>> 2b.  Do I do the right thing and put in all the extra subclasses to
>>> properly overload the whole string of dependent class references?
>>> 3.  How do I deal with 2a when the owner of the existing class
>>> modifies that method some other way?

>Schrieb Colin Putney:
>> If the existing class is part of a Monticello package, the best way
>> to deal with it is to just modify the method and save the package.
>> You've effectively created your own branch of that package, and as
>> new versions are released up stream, you just merge them into your
>> branch.

Bert Freudenberg wrote:
>This is the best way. Even better is that you refactor the package in
>a way to allow your code to hook in without code changes, and submit
>this version to the package maintainer.

Thank you for your answers.  I like Colin's solution okay, but it
really just allows me to maintain my own packages.  I'm not sure I
would want to publish a branch of someone else's package for just two
lines of code.  I don't know of a good easy way to handle package
dependencies right now either.

To address Bert's even better answer, and getting away from the
Monticello aspect of this, I am talking about adding items to the
Tweak menus in Croquet, which I would expect to be a popular and
active area for changes.  What's a good way to go about menu item
registration?

I have cross-posted this item.