Again, all semantics…

All object composition is a form of inheritance. The question is, are we inheriting the class, or are we inheriting component parts to form a larger whole?

The difference between class inheritance and more general composition in that class inheritance creates IS-A relationships and tightly couples children to parent classes, creating parent/child hierarchies (e.g., by virtue of having knowledge of the parent’s interfaces and/or internals). See “What’s the Difference Between Class and Prototypal Inheritance” and “Common Misconceptions About Inheritance in JavaScript”.

A tell-tale giveaway of an IS-A relationship is the presence of method overrides, super calls, etc…

It doesn’t matter at all what mechanisms are used to accomplish or avoid those criteria.

Likewise, it doesn’t matter at all what mechanisms are used to accomplish loosely coupled object composition. As the Gang of Four proved in 1994, composition can be implemented with classical inheritance mechanisms.

So, answers:

• fragile base example — classical inheritance
• same as above, without override — in the clear for now (composition, albeit from a single source), but avoid inheriting again from c, or you could end up creating a parent/child hierarchy. The component hierarchy should be more or less completely flat, not a tree structure.
• final example — composition, of course.

You mention the alternate languages from the final example look and work like classical multiple inheritance. Quite right. As I mentioned, you can implement composition using the tools normally associated with class inheritance, but the similarity between the resulting object design graph doesn’t look like classical inheritance object design hierarchies at all.

Forget which paintbrush you use to paint with. Look at the painting, instead.