Some keys created under HKEY_CURRENT_USER do not receive ACL for the current user

Question

I've banged my head against this case for the past few weeks, but couldn't find any explanation - my application creates keys under HKCU\Software\[app_name]\[inner_app_key], but I've received a number of reports from the field that sometimes [inner_app_key] loses the ACL for the user who's the owner of this HKCU hive and is inaccessible. You end up with the situation where e.g.:

Path   : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\[app_name]
Owner  : [my_user]
Group  : [my_user]
Access : [my_user] Allow  FullControl
         NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadKey
         NT AUTHORITY\RESTRICTED Allow  ReadKey

but

Path   : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\[app_name]\[inner_app_key]
Owner  : SYSTEM
Group  : SYSTEM
Access : NT AUTHORITY\RESTRICTED Allow  ReadKey
         NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadKey

In the situations reported the keys have inheritance turned on.

The app itself is running under the current user context. The installer classically runs under the user context but asks for UAC elevation when necessary. I also have an autoupdater which runs as SYSTEM and executes the msi installer when restarting the PC in case a new update is available. The keys can get created from the application and the installer (tech debt that needs to be fixed at some point - the installer running as admin should not touch HKCU, I know).

Like I mentioned, this was caught in the field multiple times, but I was unable to either find any reason for it or reproduce it. When debugging this, I've tried creating registry keys both as the installer and as the autoupdater (running as SYSTEM), but the keys created this way have proper (inherited from SOFTWARE key) ACLs every time. I've also tried to reproduce it by using Intune just to confirm nothing is wrong there, but again, was unable to reproduce the issue.

Are there any known issues where Windows loses inheritance of ACLs? Or are there any leads/tests that I should follow to find out why inner keys have a different owner and different ACL than the parent key? Any pointers would be greatly greatly appreciated. Can this be somehow related to e.g. some limitations that I don't know about with deployment via Intune / other MDMs and how that process interacts with the OS?

Thanks