Yes, it is valid. But there is a difference between valid and consistent/backward-compatible. Microsoft goes out of their way to be backward-compatible (but doesn't always succeed, of course) and Linus (some guy who wrote some hobby OS, that won't be "big or professional like gnu") is very adamant not to break user space if not strictly necessary and unavoidable.
To me, it looks like Apple played fast and loose here, changing the expected behavior of something as fundamental as "open", without even mentioning it anywhere (and if they didn't even notice their changes would affect this behavior, that's another problem).
A change like this does not just break PostgreSQL, dotnet (and thereby anything running on dotnet), VirtualBox, and whatever else was mentioned by name, it will break almost everything in subtle ways, because almost nobody ever implemented correct EINTR behavior in the context of these APIs.
Because they want people to consider their OS reliable? If you have software that runs just fine on the previous release of an OS, and breaks on the next one, are people going to consider the software buggy, or the OS? The perception will largely be "I upgraded to <x> version of the OS and <y> program stopped working" which quickly morphs into "<x> version of the OS is buggy because it breaks <y>, avoid it if you want to be able to do work", and if sustained long enough it then morphs into "<x> OS sucks because they constantly break software".
Take away good software and all that's left are Apple's "shinies". If it weren't for the potential game-changer that they have with the M1, I'd almost say that they wanted to kill off the Mac as anything other than an iOS development box.
When using TimeMachine as backup, rolling back to your previous OS version before the update is a rather easy thing to do once you encounter that your required App X is not yet updated to support latest version. I personally do never upgrade my macOS version before 6-12 months being released, and there is no need to since the previous version(s) is supported for several years after the release.
I'm very far out of my depth here, but from a quick read it seems like there is a commonly used flag SA_RESTART that should automatically retry these system calls instead of returning the EINTR error.
I've no idea whether the behaviour Apple introduced is allowed by the standard, but it seems that it is at least quite common to not explicitly handle this EINTR error because there is an alternative way to just tell the OS to retry instead of returning this error. So I wouldn't be so quick to claim that the downstream apps are coded improperly.
Oddly enough, POSIX does not state that opendir and readdir can return EINTR ;) - though I'm sure this must be an oversight? I doubt this is possible to guarantee in practice:
Even if it's valid behavior, it's still a breaking change. The function never set this error code before, now it does, and at least 3 large projects are not working anymore.
Could Apple be better at communicating changes like this? Absolutely. Is Apple in the wrong here? No. This is a documented return code that has been ignored. What's the point of a standard if they can't use it?
Hyrum's law doesn't apply here. Tons of software is liable to be broken by this and at least three big projects have been broken by it. Furthermore, Apple isn't even obeying POSIX since it is ignoring SA_RESTART.
Returning EINTR is valid behaviour, but not when SA_RESTART is set. The POSIX documentation for sigaction[1] is quite clear about that, even if Apple's corresponding docs[2] are confusingly worded.
