(Updated after trying suggestion from David Heffernan)
I have a legacy Win32 native app (Delphi 6) that writes values the registry under the HKEY_LOCAL_MACHINE\Software\\ key. These values are later read by several other legacy Win32 native apps and a new .NET application. The .NET app is build AnyCPU so is executing as a 64 bit image. Because it was using config written by 32bit apps the .NET software was redirecting its registry reads to the Wow6432Node that the Win32 API apps actually wrote to.
None of the applications are running elevated. All applications are interactive. The account used to run the applications has explicit "Full control" of the HKEY_LOCAL_MACHINE\Software\\ registry key and it's sub-keys.
As far as I know this was not using registry virtualisation because the 32bit apps had write access to the HKLM keys they wrote to.
This scenario has worked just fine on 64 bit Windows 7 and 64 bit Windows 8 machines, but on a new Windows 8.1 64 bit machine all is not working.
Whilst the legacy Win32 app writes to the registry without errors it now appears to be getting virtualized. This can be confirmed by looking in the users virtualized registry key; I see all the written values in there.
When I look at the HKEY_LOCAL_MACHINE\Software\\ key with REGEDIT then about half of the keys I wrote are simply missing from HKEY_LOCAL_MACHINE\Software\\ but all are present in the virtualised folder.
As I understand it with a 32 bit app with write permissions there should be no virtualisation, but there is. Worse when I read the non virtualised key I see some but not all of the values that were written to the virtualised store.
Why did it virtualise the write all of a sudden, and why would the read not show all the virtualised values when I read the original key (i.e. virtualised read not working as expected)?
I presume this must be a permissions issue as if I run the app "as administrator" the keys are all there. However running elevated is not a permissible end configuration.
Update
I cleaned out all the registry settings on this machine. Both in the virtual store under HKCU, and in the shared area under HKLM. Then started again, not running elevated. This caused similar symptoms, but this time I only see 1 of the keys in the HKLM key.
I an going to write a Win32 app to enumerate the HKEY_LOCAL_MACHINE\Software\\ key in case I am being fooled by something regedit.exe is or is not doing for me when run on a 64 bit OS and will update when I have results from that. Got it its a virtualisation mismatch between legacy 32 bit WinAPI apps and new 64 bit apps. See my answer for details.
The virtualization of the registry works just the same in Windows 8.1 as it has done in Vista, Win7 and Win8. There are no changes that can explain what you report.
Are you aware that virtualization was introduced 7 years ago in Vista to help applications that could not be modified work in the face on UAC. The idea is that you fix your application to be aware of UAC, and stop running virtualized.
The thing about virtualization is that your application will write to the virtual store if running as standard user. But if you execute the application elevated then the application writes to the shared part of the registry, HKLM. From your description above it would seem that you have run the application elevated and this has written values to HKLM rather than the virtual store.
I suggest that you clean out all the registry settings on this machine. Both in the virtual store under HKCU, and in the shared area under HKLM. Then start again with your application, not running elevated. I'm confident that it will work the same way as under previous versions.
However, I am astounded that you are still trying to use virtualization as a feature. It is a crutch to aid the helpless. Don't be helpless. Stop running virtualized. Run away from virtualization.
Update
Your question edit changes this entirely. In fact you are not asking about differences between Windows 8.1 and earlier versions. You are running a different program on your Windows 8.1 machine, one that is 64 bit. And 64 bit process are never virtualized.
Again I repeat my advice that virtualization is not to be used the way you do. It is folly to rely on it this way.