That is relying on a private implementation detail that could change in future versions.
That is true but, quite unlikely. MS goes out of its way to preserve dll names and their associated functionality.
And besides, you would still have to differentiate between 32bit native and 64bit native when the DLL is not present.
I am unclear as to what you mean there. On a pure 32bit OS, the dll is not present/loaded (quite sensible since there is no 64bit layer to thunk to.) Did I miss your point ? Also, when using GetNativeSystemInfo one has to rely on the value returned in ProcessorArchitecture to determine the bitness, it would be much simpler for MS to "fudge" the value returned in that field if it served its purposes than to change the name and/or functionality of a key system dll.
What is wrong with just ASKING THE OS using established APIs that exist for this very purpose?
Usually little to nothing but, unfortunately, MS has indulged in returning values _they_ want the programmers to use instead of the real/actual values. This seems to be particularly true when it comes to information about the OS (e.g, system directories and their actual contents - ironically, that "white redirection" (they don't lie, they redirect ... chuckle) could be used to determine OS bitness too.)
Even with IsWow64Process,
https://msdn.microsoft.com/en-us/windows/desktop/ms684139 MS states
Note that this technique [ed: using IsWow64Process] is not a reliable way to detect whether the operating system is a 64-bit version of Windows because the Kernel32.dll in current versions of 32-bit Windows also contains this function.