Sure, as in the example posted in that thread too (well, if you fix the  
example so that the "Solid" and "Gradient" classes actually inherit the  
"Base" class as I assume the poster meant them to).  Makes sense.

As explained in that thread, it's not an issue of a conflict (or at least  
I think I agree with the person who wrote that it's not).  It's a question  
of what information the compiler has at the time it compiles the generic  
class.  It needs to be able to verify the generic class as fundamentally  
correct, and the correct compilation of other code using the generic class  
needs to be compilable without looking at anything other than the generic  
interface exposed by the class.

It can't do that if CompoundObject<T> actually inherits from the base type.

Well, as was also mentioned in that thread, composition is a fine  
alternative.  And in fact, would not be hard at all.  Instead of:

    class CompoundObject<T> : T where T : ObjectBase
    {
        // ...
    }

instead use:

    class CompoundObject<T> where T : ObjectBase
    {
        private T _t;
    }

Then you get at the methods in ObjectBase that you want to use by calling  
them on _t.  If you want for CompoundObject<T> to expose the same  
interface that ObjectBase does, you can simply define the same members in  
CompoundObject<T> and delegate their actual operation to the _t object.

Of course it means you need a way of instantiating T or being provided one  
somehow.  But that's not difficult to solve either (the most obvious way  
would be to add the "new()" constraint as well, but of course ObjectBase  
could define some sort of factory, or the instantiator of the  
CompoundObject<T> could pass in an appropriate instance of T to use, as  
other examples).

It's hard to offer very specific advice without knowing exactly what  
you're trying to do.  But if all you're wanting to do is something similar  
to the "strategy pattern" example posted in that thread, I think the above  
should suffice.

Pete