If a CompoundPattern is a DesignPattern made up of multiple DesignPatterns then CompoundObjects would be concrete realizations of the abstract idea of a CompoundPattern, and CompoundObjectProgramming would be the act of creating, extending, and leveraging CompoundObjects.
CompoundObjectProgramming has many similarities to regular object-oriented programming. There can be encapsulation, the grouping of otherwise distinct language constructs into a singular entity, i.e. the class library. There can be inheritance, the layering of specialized capability on top of generic mechanisms, i.e. the library that links against another library. And there can be selective derivation, where choices are made as to exactly which patterns and classes of the base mechanism are to be overridden, which are to be reused untouched, and which are to be wrapped or altered with other mechanism.
Related to LayeredFrameworks, but with a focus on SourceComponents instead of the binary-deployment schemes of ComponentDesignPatterns.
Similar to the "virtual classes" described in this article: http://www.gamespy.com/legacy/articles/devweek_b.shtm
An example can be found in the many layers of ivtools (http://www.ivtools.org) and vhclmaps (http://www.ivtools.org/vhclmaps) built on top of the UnidrawFramework which incrementally specialize the TooledComposite pattern at its core.
See Also: JwamFramework, ModelViewControllerAsAnAggregateDesignPattern