I understand the stated reasons and disagree with their conclusions. It seems like a lot of extra work on the part of the Zig developers to have to reverse engineer undocumented interfaces. There is potentially extra work for the Windows developers if they want to change their private implementation details that Zig programs are now relying on. And in the case where the lower level APIs are missing features implemented higher level APIs, Zig has to either reimplment the functionality themselves or not have the same level of support for Windows features that normal Win32 apps have. A concrete example is looks like Zig programs can't open serial devices:

https://codeberg.org/ziglang/zig/src/commit/6193470ceea89a98...

All this to save a little memory CPU and memory usage? The juice does not seem worth the squeeze.

"As Zig has evolved, it has become a target to avoid calling Win32 APIs from kernel32.dll etc., instead using lower-level ones in ntdll.dll."

If we needed an example of why we should avoid using passive voice, this is it.

This sentence doesn't include examples of the passive voice.

Ha, you're absolutely right. The "has become a target" got me there. So glad, Zig wasn't targeted there.

The sentence that you quoted is more generic. The Zig issue is only one example of "some reason".