Does this code or proposed design exhibit sound engineering given the project goals?
> As I said, unless you plan to rewrite Linux from scratch in C++, any
> proposal on the table is about using a restricted set of features in some
> parts of the kernel.
Why? There is nothing magical about the kernel. It's software. Even in a project transitioning from one implementation to another, there's no reason to artificial limit what people are allowed to do, especially _a_priori_.
> What other language after C++ uses multiple inheritance, has virtual
> base classes, uses "protect" or equivalent, allows slicing, etc.?
Ah, good, some concrete points.
Multiple inheritance is very useful. If a language with inheritance doesn't have it, it has a major missing feature.
Virtual base classes are trickier. They are painful, I admit, but necessary for some uses of MI. Many uses of MI don't need them at all. C++'s possible mistake was to place the decision point at the intermediate class level rather than at the "final" class level. But it's a convenience/efficiency tradeoff and I'm not totally sure the committee got it wrong..
By "protect" I assume you mean "protected." Protected methods certainly are useful. Protected inheritance, not so much but I'm sure someone has a use case for it.
Slicing is also a big pitfall. But I think it's a natural consequence of call-by-value semantics. One could argue that C++ should have made call-by-reference default but that would have broken C compatibility, a major strength of the language.
> I'm happy to be enlightened if there is a language out there that said
> "C++ inheritance is spot on, let's copy it".
I don't think anyone has said that. I have not said that. To do so would be to say that the language is perfect, an impossibility in an imperfect world.
There are valid criticisms of C++. But to take that to an extreme and proclaim the C++ inheritance model "broken" or "wrong" is, well, wrong.