And that is perfectly OK! Any "module system" sucks big time, creates more problems that it solves, and should be avoided whatever the cost. Textual includes are great but of course they should not be used for silly module systems.
Module systems solve all the problems mentioned in the argument (and created by text-based imports).
By themselves, they don't add anything bad on their own.
What exactly are those "more problems that it solves"?
The C language is not designed for building huge programs by accretion of modules. The idea is that you build many independent programs, and then you glue them together using scripts.
Can you give a single concrete example of a problem, because the above are all noops semantically speaking...
>The idea is that you build many independent programs, and then you glue them together using scripts.
This is a non-starter for most use cases outside pipeable shell commands (which are not the only kind of programs people want to write).
People need, and write, and have written for decades, large programs in C, and programs in C which have from 10s to 100s of headers files included (including recursively from included libs).
The idea you mention is valid, and is part of the Unix philosophy.
But it was never the idea that C should be used JUST for that.
In fact the first use of C was to write a whole operating system.
That doesn't exactly describe kernels or embedded systems, which are C's strongest bastions. Whether it's well designed for the purpose or not, whether modules are appropriate in that context or not, a significant majority of the C code out there (including most common web servers, databases, etc.) does not fit your description at all.
Building small programs and gluing together with scripts is great, but hardly relevant. You don't need includes or modules for that. What if you do need to build one large program, like those aforementioned web servers or databases, or (what I work on) a storage server? That's where the difference between textual inclusion and modules really comes into play, and modules are strictly better than includes in every way.
I think the problem here is that you're confusing modules with things built on top of modules - specifically package managers. A lot of the package managers out there are horrible and create more problems than they solve, but that has almost nothing to do with modules as a language construct.
Must be nice to have one of those! Cortex-M* does not.
Imagine you change code in an upstream module. Now the compiler has to recompile all downstream modules. In C and C++ this only happens if you change the header file. (On the other hand modern development techniques emphasize tests so you might only recompile your module and the testsuite until all tests pass and only then recompile all modules, minimizing the impact.)
For a full recompilation you can parallelize C and C++ compilations much better than any module system I know.