The consumers of the Native API are things like the original POSIX subsystem, the Interix POSIX subsystems, the OS/2 subsystem, the fourth POSIX subsystem used in WSLv1, NTVDMs, and of course the Win32 subsystem. Some of these were frozen long ago. The still live ones do not necessarily change in lockstep.
That said, for those particular API functions there is an interesting history that is, rather, about mitigating security holes:
Yes, but the Native API is NTDLL, a userspace wrapper around the system calls. On Windows nothing except NTDLL is meant to invoke system calls directly, and my experience was that this is basically true. Some apps will bypass the Win32 subsystem and link against NTDLL directly (which they aren't meant to do), but outside of a handful of very obfuscated video game DRM systems and malware, not much is invoking system calls directly.
Changes to the system calls to close exploits are clear, but I'm really curious what software is invoking NtLoadKey directly that Microsoft themselves can't change, and then kept doing it even as the system call evolved over time. These aren't documented even in headers so it takes some reverse engineering to be able to do that.
That said, for those particular API functions there is an interesting history that is, rather, about mitigating security holes:
* https://www.tiraniddo.dev/2020/05/silent-exploit-mitigations...