>>18
If you're trying to say "the problem doesn't exist" because you can customize it, well yeah, C++ does the same thing. You can specify the order of your base classes, and you can specify a base class as using virtual inheritance, and you can always just overload a method to specify a superclass if you want to override the default order.
Languages like Python have much bigger problems with multiple inheritance than C++ because all bases are virtual by default and there is no way to configure it; the MRO is done by C3 linearization. There are an amazing number of pitfalls in Python inheritance; for instance even if you specify no base class (i.e. just subclass object), your __init__() still needs to always take *args and **kwargs, popping the arguments it wants, and it still needs to call super(Foo, self).__init__(*args, **kwargs). Otherwise if your class is used in a multiple-inheritance scenario it won't call the next __init__() in the MRO chain.
So yeah, as painful as the syntax is in C++, its semantics for multiple inheritance are actually fairly sane. Language designers don't generally dispute this actually; they usually leave out multiple inheritance because it's easier on compiler writers. Just ask James Gosling; that's really the big reason why Java does not have multiple inheritance. He was just lazy.
I am in support of multiple inheritance because a class should be able to include many interfaces that add code (not just prototypes.) Many modern languages support this sort of paradigm, though they call it different things (like type traits). It's sort of a half way between multiple inheritance and simple Java-style interfaces; you get code but not class fields.