I disagree with it very deeply. I don’t feel up to writing my usual longposts, so I’ll try to state the problem succinctly.

The problem with this mindset is along two points, the first leading to the other. The first is that the C, and it’s resulting semantics, are very tightly coupled to the machine and operating system it is running on.

While we have mostly normalised on x64 and the SYSV ABI, this was not always the case, and even today it is not always the case. To write "correct C", you absolutely have to know the platform and the OS on which it is deployed, and said C code cannot be considered correct between "foreign systems" (i.e. systems where integer behaviour is different, where the system interfaces are different, etc.). The C standard ratified and smoothed over a lot of these disparate C’s, but they left UB to give enough wiggle room for different platforms and architectures (Look through Annex J. Most of the entries in there are either "we cannot guarantee in the circumstance that the implementation is faulty" or "we cannot guarantee you will be on a machine with these semantics". Yes, the GCC developers later abused those to contradict normal developer assumptions in order to game extra speed out of it, but IMHO that wasn’t the original intent of Annex J).

Thus, interacting with a C package would require the package-maker to consider all of these disparate systems and platforms — Illumos, ARM, MIPS, i386/x64, Linux, Windows, 9front, etc. Even Rust, today, does not support the full compliment of systems that C supports. And again, each of those systems might have different calling behaviour and pass parameters in a unique way, each of those systems might handle integers and floating points in a different way. Do not think of this as a failure of the C standard itself, as the C standard was designed to unify a fragmented C ecosystem, where each platform had its own C. It can only do so much to rectify these differences.

This is the reason why distributions ship with their own versions of packages, here we come to the second reason — language package managers almost always end up reinventing the wheel in terms of what Linux repository maintenance teams do, often senselessly, for no real gain. The packages in a repository (most of the time... I’m thinking of the mid 2000s here, before language-package management really took off, think Debian, I guess) have been vetted and altered by the package maintainer to ensure that they conform to the correct specifications of the machine and the OS. There is a lot of infrastructure that comes with this — vetting the packages, ensuring they have correct behaviour, backporting security flaws, ensuring the code isn’t malicious, etc. — that the designers of language-package managers, in their hubris, thought they could do without. And npm and pip and so on, have spent the last decade learning the reason why those systems exist the hard way, having to reinvent most of that infrastructure from scratch, sometimes successfully, sometimes unsuccessfully.

I think that between these two problems, the result is that a language-specific package manager for the C language would be a lot of work for very little gain. It would duplicate a lot of effort, a lot of the distribution supply chains and funding, and the packages still wouldn’t be universal, because in each case the developer would still have to ensure that it conforms to your platform and architecture specifications anyway — otherwise, that’s UB territory, and GCC has meant the prevailing attitude towards UB by compiler developers is very unkind and very hostile to both the programmer and the user. It’s a replication of effort for very dubious gain, at best.

Welp, I guess this did become a longpost.