multi-language code base

Yes, what about them? It is a mess. It is not as big mess as it could be.

Lets count them:

a) C
aa) CPP (see below)
b) inline asm
c) real asm
d) BPF
e) lonely bc script for time conversions
f) Kconfig/Kbuild
g) Makefile
j) yaml for netlink and hardware configs
h) random junk (bash, rpm, deb, everything else)

Only 3.5 execute on users machines and total amount of asm and BPF is quite small, so it mostly OK.

Now let's examine them more closely.

* C preprocessor is bananas.

You can't even write

#if sizeof(int) != 4
#error
#endif

It just shows how they made terrible decision in the past and never fix it (by integrating the PP part with C part).

Kernel PP part is quite bad, large parts of Very Important kernel code (preemption, locking, percpu accessors, rcu, __user stuff)
goes through CPP. At some point I realized that it is faster (and more reliable) to preprocessor some files and indent them
then to jump with tags over macrology sometimes unsure if you've jumped the the right place.

Now that _Generic is allowed to be used, and at least some desire for ad-hoc polymorphism
there will be more preprocessor in the future.

I wrote the equivalent of "template<typename N, typename D> kdiv(N n, D d) -> N" at some point.
Thanks God, I never sent it (dispatch on 2 args, ouch).

So, there will be more (garbage) sub-language in the future which is apparently will never get better.

* inline asm/real asm

AT&T syntax is the worst part of it. It became more macro heavy over time because of speculation fixes and getting more annotations.
Visually it is less and less an assembly.

* BPF

Jit over primitive VM -- whatever. Can't they load and verify real assembly?

* bc(1)

This is raw inability to constexpr.

* YAML

This is probably papering over anemic macro/constexpr system of the main language.
Using whitespace-sensitive language should have never been allowed in the first place
(because everything else is whitespace insensitive except tabs in Makefile).

* Kconfig/Kbuild/Makefile

The argument here is basically, if you trust you main language to write OS kernel of all things
they why don't you trust it to use it to build itself.

Makefiles are very different anyhow: mix of declarative and imperative programming.

> Arguing "I don't want to learn a second language", when it's almost impossible to contribute without knowing three, four, five or more, is disingenuous in the least.

Nobody is arguing this. I know a few too.

> And lastly, as a (not that good) linguist myself, I would STRONGLY argue that knowing several languages typically makes you a better linguist IN ALL LANGUAGES.

Ever heard of the Tower of Babel? :-)

> But saying "new languages are bad" as a blanket rule is just so awful it would be laughable if it wasn't tragic.

The statement is "new main programming language is bad unless it becomes the main programming language in foreseeable future".

> And if a Rust DMA manager arrives in let's say a year or so, which appears to be roughly the equal of the C version in maturity and bugginess, I think the writing will be on the wall for old dogs ...

There is nothing to be proud of as each distro has to decide which one to use, make effort to support both, splitting userbase, sorting bug reports, telling users to try the competing module, you know, all the good stuff of Open Source day-to-day life.