One of the reasons I would not favor a TreeNode abastract class
is that the thing I want to reuse is the pattern, and possibly
multiple times within the same class.

For instance, to a certain extent this happens whenever I maintain
several collections of different things within an object.  Having
a superclass in which only one of these one-to-many relationships
is covered does not help.

That's why I do not bother with a commonly used TreeNode, but instead
manually do the work that a parameterized mixin could do for me.  I
do the rubberstamping because I currently do not have a facility within
the system to accomplish the same goal.  Such a facility would have to
manage more than simply stamping out code- I would want it to do
things in a manner such that good software engineering and reuse
practices become a natural part of working with the environment.

As far as running inheritance ( delegation, actually ) through
patterns... that would be an interesting project for someone.
The motivation is based on the observation that many patterns
are used again and again, that there are variations in implementation
of these patterns, and that quite often I am able to parameterize
them and stamp them out on a grand scale.  At that point I am not
writing individual methods nor specifying individual instance variables,
I am saying "put this pattern into that class".  That is a different
mode of programming, and it will require a different set of tools
to facilitate it.  One aspect of that might be that it would be
worthwhile to run inheritance and behavior through behavioral patterns 
rather than classes, which accumulate several patterns into one context.
This leaves the issues of working out how to deal with the inter-pattern
interactions, and the extent to which individual patterns are decoupled
from other patterns in a given context.  In that model, classes are
contexts in which patterns live and interact, and ideally to the
greatest extent possible the atomic particles of a class would be
individual patterns, rather than individual methods and instance
variables.  Or, in another way, the patterns within a class context
would be the instantiations of pattern "classes".  Something like that...
Whether this would ultimately be good or not I have no idea.

BTW, I am sure that this is a somewhat different connotation for the
word "pattern" than that used by the Patterns people... the problem 
is that "pattern" is such an appropriate name for what I have in mind,
but unfortunately it was appropriated decades ago and I don't have
a decent replacement term to use instead.  So keep that in mind...
I don't intend to redefine the term, I just haven't found a better name
for what I'm after.

les