Understanding the exposition of Alexandrescu about

Question

UPDATE: I have asked a narrower question here.

On pages 6-7 of Modern C++ Design, Andrei Alexandrescu gives a very fundamental discussion of the strengths and weaknesses of two C++ language features -- multiple inheritance and templates -- with respect to building flexible designs. He concludes:

Now compare the list of drawbacks of multiple inheritance with the list of drawbacks of templates. Interestingly, multiple inheritance and templates foster complementary tradeoffs. Multiple inheritance has scarce mechanics; templates have rich mechanics. Multiple inheritance loses type information, which abounds in templates. Specialization of templates does not scale, but multiple inheritance scales quite nicely. You can provide only one default for a template member function, but you can write an unbounded number of base classes.

I can sense that what Andrei says here is very important, but I cannot really understand what is being said without any examples to illustrate the points. This question is asking to provide simple examples to illustrate these points (please continue reading).

To make the question more specific, I would like to ask to please focus on the weaknesses of multiple inheritance. This is what Andrei has to say about them (the text in square brackets is mine as per my understanding of the context):

In such a setting [i.e. multiple inheritance], [to build a flexible SmartPtr,] the user would build a multithreaded, reference-counted smart pointer class by inheriting some BaseSmartPtr class and two classes: MultiThreaded and RefCounted. Any experienced class designer knows that such a naïve design does not work.

Analyzing the reasons why multiple inheritance fails to allow the creation of flexible designs provides interesting ideas for reaching a sound solution. The problems with assembling separate features by using multiple inheritance are as follows:

1. Mechanics. There is no boilerplate code to assemble the inherited components in a controlled manner. The only tool that combines BaseSmartPtr, MultiThreaded, and RefCounted is a language mechanism called multiple inheritance. The language applies simple superposition in combining the base classes and establishes a set of simple rules for accessing their members. This is unacceptable except for the simplest cases. Most of the time, you need to orchestrate the workings of the inherited classes carefully to obtain the desired behavior.
2. Type information. The base classes do not have enough type information to carry on their tasks. For example, imagine you try to implement deep copy for your smart pointer class by deriving from a DeepCopy base class. But what interface would DeepCopy have? It must create objects of a type it doesn’t knowyet.
3. State manipulation. Various behavioral aspects implemented with base classes must manipulate the same state. This means that they must use virtual inheritance to inherit a base class that holds the state. This complicates the design and makes it more rigid because the premise was that user classes inherit library classes, not vice versa.

I would very much appreciate a simple example for each of the three items above. Each example would show both one limitation of multiple inheritance (e.g. poor mechanics) and how templates do not possess this limitation (Andrei wrote that "multiple inheritance and templates foster complementary tradeoffs").