I prefer a different solution--avoid testing for specific major modes.
Instead, use local variables set by the major mode. This makes
inheritance possible between major modes.
I suspect the people who "cannot help but question" this are a fairly
small. There is no factual basis to claim that people in general, or
even programmers in general, will have this experience.
I installed derived.el because it does the job that actually needs
doing, and was a small amount of work.
Emacs Lisp is powerful enough. Adding OOP to Emacs is not clearly an
improvement; I used OOP when working on the Lisp Machine window
systems, and I disagree with the usual view that it is a superior way
to program. But even supposing that OOP would make Emacs better, it
is lower priority than many other changes (mostly in editing rather
than in Lisp).
Where did you get this info? I'm not contesting it, just curious.
I was under the impression that RMS was moving toward a Scheme-based
extension language (GUILE), and that this would eventually be used in
emacs as well as in other GNU SW. In such a case, there are good OO
Scheme packages already existing that could be dropped in.
(proclaim '(inline skates))
One possible solution, then, is to have simple variables
"c-mode-likep", "c++-mode-likep" and "objc-mode-likep" which not only
would eval to t for their specific major modes, but also eval to t for
any newer major modes that descended from them.