How does this apply towards library creation, where the code is meant to be consumed by other programs languages?
While the total lines of code in libraries is less than that in applications, I would say the relative importance is more. That zlib has a fast and correct implementation matters to a lot of people.
That's right; one fast and correct zlib matters more than giving everyone an improved C so that they can all try to roll their own zlib that is fast and correct.
My comment was mean to point out that even if we magically achieved your dream tomorrow, and almost all applications were written in some HLL (which is probably a good thing), the amount of machine code being run in those applications that was generated from C is still substantial due to library use. If we accept that C is "bad", or at least that some major gains in usability, reasoning and security can be made by changing or replacing it, then there's still a major benefit to doing so.
When a bug comes out in zlib (or more likely, OpenSSL again), and we can attribute it to poor engineering in C, it doesn't really matter that all the applications are written in a HLL if they still loaded the library and used it because the performance was needed.
"Let's make an improved C, and then write millions of codes in nothing but that" is a myopic non-starter.