This is different: C has to be implemented efficiently on a wide range of hardware, almost without regard for how good of a fit that hardware is for C or any modern language. Machines with 36-bit integers and 18-bit pointers? They got C compilers. Machines with no native notion of byte addressability? Plenty of C compilers for those things. Machines with application-visible segmentation? Of course! Those machines were quite popular for a while.
Therefore, the C programming language has to at least try to make it possible for portable programs to exist. That's the implied contract of the C standard: Code to the standard, and your programs will be compilable and runnable on every platform targeted by a conformant C compiler. So, since int is going to be a size adapted to the hardware, as required for efficiency, the programs have to know how big an int is, as required for portability.
> Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people.
No language standard specifies that, I'm pretty sure. The ES6 standard doesn't specify left_pad and the C++ standard doesn't specify Boost. However, the standards also don't specify things which could replace those external libraries in a portable fashion which is guaranteed to always be there. If you take something out of the standard library, it has to go somewhere; people aren't going to stop doing that thing just because the standard no longer mentions it.
This works so well you may have hardly even noticed its so widespread as a solution to the problems you describe.
Makes me wonder why Lisp is cursed[1] but C++ isn't.
[1]: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
There are so many build systems in C and C++ because for each of those, someone finds something to be inadequate and has something else that works for them.
Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not.
These languages are meant to not impose a lot on the implementer or practitioner. Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. It is a misguided suggestion. I think it mostly comes from people not working in the language, or unfamiliar with code bases that are working well as-is.