Common grounds and uniformity - if every library were using it's own build system it becomes very hard to combine libraries. See c++ for example, when including a library you always have to either wrap the build, rewrite it to your build system or find a a way to prebuild. And every library is unique. Contrast this with other systems where you just add a line to your package.json file. Big red flag is that people come up with those header-only libraries or single .c-file only libraries, just to get around the problem of package management.
Language rules define dependency rules, that the build system is not aware of. For example transitive #include chains, requiring stuff like gcc -MMD to generate makefiles. This also improves IDE experience with suggestions on where to find imports instead of elementary error messages like "header file not found".
It has a lot to do with the language because the ease of adding external libraries has an enormous impact on the design choices made when writing code.
Also, the need for header files and disgusting hacks like unity builds just adds unnecessary friction.
> ... language because the ease of adding external libraries has an enormous impact on the design choices...
even if you could incorporate external libraries with zero impedance mismatch, you still have to _use_ the said libraries.
while there might be _marginal_ element of truth to that statement, however ease of stitching external libraries into your application has no bearing on either the programming language or the act of programming the application itself.
I don't understand what you're trying to say. Of course the effort to include the library in the project and keep it up to date has an impact on the decision whether I use it or whether I just roll my own. There is a reason that my Rust projects have dozens of dependencies whereas in C++ I basically restrict myself to boost or other header-only libraries.
50% of the popularity of modern languages like golang and rust comes from the fact that building and dependency management is light years ahead of older languages.
Your original argument was that the ease of dependency management doesn't change programming or the act of programming. I feel it encourages a compartmentalized approach to writing programs, pulling in dependencies as needed rather than relying on a giant library like Boost. Thus it does actually change the "act of programming", which is a vague term that can mean anything.
This is not mentioning all the upsides of having a easy build system from easy learning and community standpoints.
The current trend of combining the two concerns by having language-specific build systems (like Cargo) was a mistake, IMO.