You just added a DNS lookup to connect(2).

Also, you linked socket creation to all of this. This would make it hard to do an asynchronous version. Today you can create a socket and do a non-blocking connect(2) (after doing your asynchronous DNS lookup)

Lastly, I think if you tasked someone with creating that API, they would probably use the old APIs to build it ...

If you're doing that, though, you'd better dang well give me secure key storage in the Kernel, too, or full TLS capability. Allow my program to n load it's RSA/ECC key at startup, then drop privileges to access that file, and have a kernel module handle the cryptography.

If there's enough volume of requests that a kernel level cache meaningfully improves real world scenarios, something is broken in those scenarios. :p (but I think you agree with me)

Certainly you could implement these functions using the existing BSD socket libraries, but that misses out on having them used everywhere so you get "free" IPv6 transitions and whatnot.

Your example would fit perfectly in a libinet library, but I doubt the C standard library is going to include improvements upon this. If you want good internet support, pick a library or, better yet, another language because plain C is terrible for managing arbitrary network inputs anyway.

There is also some stuff your code doesn't handle (do you retry when a connection fails but an SRV record lists multiple options? who is supposed to free the inet_err struct, because your example leaks memory? how do you handle attempts to connect over IPv6 on hosts still stuck on IPv4 only?) that I would expect a low-level C interface to be more explicit about.