Registry Keys written to wrong location ?!

This looks like an access and privilege issue. Is this an Ordinary User or an account with Administrative Privileges? Try running the application as Administrator let's see. Ordinary User accounts cannot write to HKLM but they can read.

Its a script running on my personal machine and I am a member of the admin group.

If it is a privilege issue, I would expect it to error out and not write at all ?

Thanks

The script might not be running as Administrator. Windows introduced UAC. Even if you are a member of the admin group, it doesn't not automatically mean that all your processes run as admin.

So your telling me that the path of key actually gets redirected to a location in the HKEY_USERS  hive ?

I would expect it just to return an error ?

Yes. There are various scenarios where registry redirects are applied. Yours is registry virtualization.  

• Registry Virtualization: Registry virtualization is an application compatibility technology that enables registry write operations that have global impact to be redirected to per-user locations. This redirection is transparent to applications reading from or writing to the registry. It is supported starting with Windows Vista. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a per-user location within the user's profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software). Here is an example from someone on the FSLogix team
• WOW64 - 32bit applications: When writing to registry on a 64bit machine, but from a 32-bit process, some redirection occurs. Redirected keys are then mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. 

Resources: 

• https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-virtualization?source=recommendations
• https://learn.microsoft.com/sv-se/windows/win32/winprog64/shared-registry-keys

"I thought writing and reading reg keys was straight forward?"

I guess this depends on your definition of "straight forward"!!

This is a real Matrix Red or Blue pill time, take the blue pill and stop reading here, take the red pill and stay in Wonderland and let's see how deep the Registry Rabbit-Hole goes ....

The short answer is that HKLM doesn't really exist (!) or at least it doesn't exist in the same way that the other registry hives exist. It's a summary of all the other hives that represents the current state of the system, software, hardware and users.  This is where the operating system goes when it needs to know the location or setting of anything.

It's built out of all the other hives.

I'm guessing at this point you're going to want a longer answer (I know when I first explored this I needed a lie down!)
So, remember there are multiple hives in the registry and the the registry is there to contain all the system variables (ALL of them, EVERYTHING that Windows needs to know to keep running correctly).  Grab yourself a very strong coffee and prepare to discover why everything you thought about HKLM was wrong!

Let's just use a couple of other hives in a "compare and contrast"

HKEY_USERS (HKU) - contains user-specific configuration information for all currently active users on the computer. This means the user logged in at the moment (you(!)) and any other users who remain logged into their sessions on the PC but have since "switched users" (If there's an active user you isn't you and you attempt to shut down the computer you'll trigger the "Other people are logged onto this computer. Shutting down Windows might cause them to lose data. Do you still want to continue shutting down?" pop-up.
Each registry key located under the HKEY_USERS hive corresponds to a user on the system and is named with that user's security identifier, or SID.  In your link above yours shows as S-1-5-21-930123263-764908089-2895329306-1000, (the last four digits represent the order that user profiles were created so this is the first profile on the PC) The registry keys and registry values located under each SID in HKU control settings specific to that user, installed printers, environment variables like mapping, wallpapers,  personalisation etc, and is loaded when the user first logs on.

HKLM\SOFTWARE\Wow6432Node\ is seen on 64-bit versions of Windows and is used by 32-bit applications. It's the equivalent of HKLM\SOFTWARE\ but isn't the exact same as it's only there to provide information to 32-bit applications in a 64-bit OS. WoW64 presents this key to 32-bit applications as "HKLM\SOFTWARE\."

That brings us to HKLM!HKEY_LOCAL_MACHINE (HKLM) doesn't actually exist anywhere on the computer, it's a virtual container for displaying the actual registry data being loaded via the subkeys from other hives that behaves like a hive itself.  Most importantly everything you see in HKLM is made from other hives, HKLM is simply full of shortcuts pointing to them.

Because of its "non-existent" nature, neither you nor any program you install can create additional keys under HKEY_LOCAL_MACHINE however if a registry script tries to write to HKLM it is automatically redirected using these shortcuts to the real hives as appropriate at the time the script is run. Those changes are then reflected in HKLM (even though the change was made elsewhere - in your question your script writes to HKLM
but what really happens is HKLM redirects the change where it really needs to go > HKU under your SID.  If you later search for the contents of the HKLM location it loads from HKU.

The virtual hive HKLM is "global", meaning that it's the same no matter which user on the computer views it, unlike a registry hive like HKEY_CURRENT_USER (HKCU), which is specific to each user that views it while logged in. This shortcut system protects legacy locations and acts as a safeguard that changes get made to the right hive in the right place at the right time.

Here endeth the lesson :)

That's really good to know ☠ MASQ ☠ . Registry is indeed anything but straight-forward.

your script writes to HKLM but what really happens is HKLM redirects the change where it really needs to go > HKU under your SID 

Just trying to probe for more information from you => If HKLM writes to HKU\SSID, does that then not become the same as HKCU since this is also now tied to the currently logged-on user's SSID? I'm wondering how HKLM then maintains those global settings which apply to "all" users on the machine (i.e. regardless of the logged-in SSID).

That's a really good question.

As a generalisation:
HKLM stores values related to programs (eg path to installation same for everyone)
HKCU should only be used to store user-specific settings (personalisation)

Writing to HKLM to directly affect HKCU settings is fraught with issues to do with current user permissions - normally HKCU shouldn't have admin rights and so changes to HKLM may not be allowed - it those circumstances scripts should address HKCU directly.  Even so a .reg file merge may need elevated permissions.

So, Lots of good info there.  Back my original posted question: Decoding  you answers, everything is working as designed ?!

but as Mlanda T  asked, What path should I be using so that my values are saved as global on not local to the user ?

Thanks

Depends on what you want to put where and if you need to read it back from the Registry, I realise that's going to sound pretty vague but it would be helpful to have a specific scenario with real Keys to answer your question.

Also storing configurations in the system Registry is increasingly deprecated over using the AppData folder in Windows

This is to be used in an HTA "VBScript" app, not a compiled application,  So the APIs to read and write INI files are not readily available. Recreating all that in a script would be time consuming and could cause that section to become larger than the script its self.  Its easy to write and read from the registry with the methods located in  "WScript.Shell" object.  Is there a simple way to Read and Write INI files w/library built into Windows ?

Thanks

Windows installers and WScript are well outside my competency, might be worth looking at a more focused question in VBS for help with this
https://www.experts-exchange.com/topics/vb-script/