This isn't about making error messages more friendly, this is about providing a hack because most software is broken. If software reported and recorded errors precisely when they happened, this wouldn't be an issue. The application making the request has much more relevant contextual information than the operating system does. And context that is inaccessible to the application is usually supposed to be that way for security. You're not supposed to know which policy blocked your request. (Things may be different if you're a sysadmin, but you want a separate, protected channel for that information.)
Yes, it's tedious to deal with errors early, but everything is tedious in C. It's the nature of the language. C isn't a RAD environment.
Let's not pretend that this proposal is a better errno. It's a work-around for broken software. It's equivalent to wrapping every error in an exception, and pretending that exceptions fix the tedium, instead of what they usually do--kick the bucket down the road.
Now, that doesn't make it a bad proposal, per se, just not what it's advertised as.
As for dealing with errno munging, the simplest answer is to not use errno. Capture the errno value immediately after a system call fails. And stop writing library APIs which write through errno; instead, return a friggin' int directly. Why people use kernel error reporting semantics as a prototype, I'll never understand. When I see application routines which return -1 to signal an error, I want to tear my hair out.