Almost half the comments here are just to remind everyone that C can/will never be replaced. Is that really the most insightful we can be? Is HN so pedantic now that we can't analyze an interesting language idea, but just nitpick at its existence?
1. Make a language and compiler that fills the same niche as C but does it significantly better, taking into account all the lessons we've learned in the last 44 years.
2. Make a build tool that competes with autotools, cmake, make, etc. Similar to Python build.py, you'll have a build.zig, import a library and use it. The library does everything configure/make does except better.
3. Package management on par with NPM and Cargo. Minimal overhead to publishing reusable code. Although I don't plan to have a central repository, rather the ability to put a URL or source control URL with a hash.
4. Zig can import and export .h files, and you can target .o files that are compatible with the rest of your C codebase.
5. Now there is minimal cost to replace bits and pieces of your codebase with Zig.
6. Talk about Zig at conferences and promote it in other ways
Points 2 and 3 don't really belong in a programming language.
If I were to build a language, a headline feature would be a package repository that enforces best practices (e.g. it should outright refuse to publish a minor version upgrade that breaks the ABI).
Any 'process improvement' scheme will necessarily need to be language-agnostic to achieve popularity.
The niche of C is Unix, which is here to stay. C is a part of Unix, it's interfaces are defined in terms of C, and plethora of libraries written in it. If a random library X is impemented in C, it is easily usable in many languages via FFIs. Programs written in C are easily portable to most popular platforms, and C knowledge is transferable from supercomputers to tiny embedded devices. C translates nicely to assembly, and it maps easily to mechanics of computing. These are the areas where languages like Zig need to penetrate.
OS package managers fulfill a different task than development package managers that are bundled with programming languages.
The OS package manager provides a consistent set of libraries that is required to run the applications that ship in the OS.
A development package manager is used to bundle all your dependencies and pin them to specific versions so the build is reliable and reproducible. This sometimes involves things like being able to have several versions of a library in your dependency graph. Or sticking to a specific older version of a library you need (because their release schedule might not align with yours).
A development package manager might also take care of the compiler/interpreter version(s) of your programming language, for languages that develop rapidly. Heck, I'd even want this for "slow moving" languages like C, where I sometimes end up requiring a recent-ish compiler version for some extensions/intrinsics I might be using.
Apart from some fundamental libraries (say, OpenSSL, Xlib, libc), you should not rely on your OS package manager if you wish to reliably and reproducibly be able to build your software. The rest you should probably link statically or bundle with your app binaries depending on how you distribute your software. If your software ends up being packaged for a distro, it's up to the package maintainers to ensure that it'll build and run with the other libs in the OS.
I do agree that it is a nuisance to have a package manager for every language, but so far no-one has stepped up to try to make a unified package manager that works with many languages.
Still I can't help but ask one question: Your points 2 and 3 (build tooling and package management) seem like they would have the biggest, immediate impact for most current c/c++ users.
Did you ever consider separating the build tooling and dependency management effort from the core language?
I, for one, would be extremely interested in sane build tooling and dependency management for c/c++ (and what you describe sounds great). I would give it a try in no time. However, I'd be much more hesitant to consider a new language for a serious project. Even if the language is tip top, I would still be concerned if it is likely too be around and still relevant in X years. I think build tooling has less of a chicken-and-egg problem to adoption because you could always switch to another tool later. And once somebody uses your build system you're already half the way there to using the full thing.
As far as I can tell, this view is completely consistent with this PL's author's view.; he aims to leverage existing C code based and gradually switching parts over where possible; that's embracing C rather than shunning it.
Had UNIX been a commercial OS instead of having the source code available for free, C would just be another footnote on the history of system programming languages.