Only in an Active Directory setting, which the vast majority of home users do not have. And even then, the AD administrators need to take extra steps to enable this functionality; it is not on by default, as some web articles have incorrectly opined. The hooks are there to allow it, but the admins need to specifically enable the desired policy and security settings. The ones that do usually use this in limited environments, such as call centers, where there is a standardized workstation build, more workers than computers, and no assigned seating. Such environments usually do not allow unapproved applications to even be installed in the first place if they are not specific to the job function.
If your computer is not in an AD domain they are functionally the same.
In order for it to be reliable, you either need an on-prem AD deployment or an Azure AD employment, and your workstation to be joined to AD or Azure AD, and the proper policies set, for Windows to take advantage of the roaming profile feature. This requires either the Window Enterprise or Education SKUs; Windows Home and Pro do not provide the necessary functionality.
The commercial-side cloud facing roaming functionality has historically been…moody…and is really intended for small configuration files, links, etc. There are specific modern APIs your application has to use in order to make use of it and a whole host of limitations, and I’m not sure if legacy Win32 apps can use those APIs to be honest. Scrivener is definitely a legacy Win32 app, not a UWP app.
There’s also the point that using this feature is in no way cross-platform compatible (without using the Azure App Services API, which implies additional costs for the developer in terms of the back-end Azure infrastructure.) There’s also the question of whether this would be suitable for all of the small subset of users who would take advantage of it; maybe they use different devices for different purposes, and not want those files shared.
I would honestly expect L&L to look into some way to leverage per-project personal words lists that get synced with the rest of the project files (and can thus be shared across Mac, Windows, and iOS) before trying to rely on fragile, platform-dependent functionality like this.
Inside the command prompt window type mklink wordlists.ini, then add a white-space and press the right button of your mouse. This should paste the path you copied at step 2.
The command line should look like this:
Hit Enter. If you did it correctly, a new wordlists.ini should appear in the folder C:\Users\%userprofile%\AppData\Local\LiteratureAndLatte\Scrivener\. If it doesn’t, you might need to run the command prompt as an administrator. I won’t post how to for now. If somebody needs help on this, just ask.
That’s it! Your words list is now synced in cloud.
Explaination: What you have just created is a soft-link to the file contained in your cloud folder. Think of it as an advanced version of shortcuts. Whenever Scrivener reads from/writes to the wordlists.ini, it’s redirected to the linked file in a trasparent way, thus reading/writing to the file your cloud client (Dropbox, OneDrive, …) is monitoring. IF you set it up correctly, it’s 100% safe. Scrivener will never know what happened…
EDITED: I changed the guide from hard to soft linking, because Scrivener seems to delete and recreate the wordlists.ini EVERY time you add a new word. If hard linking, this means you actually deletes the alternate identity of the file and recreate a new copy of it, disconnected from the one you stored in your cloud folder. Using soft link, instead, you force a transparent redirection, and Scrivener will operates directly on the file in your cloud folder, without deleting the soft link (aka symlink)
Note that hard links should be on the same hard drive volume as the file they link to for this to happen, otherwise you’ll get a symlink.
I also don’t know where the guy who wrote that file you link to came up with “soft links” – classic Windows terminology has been “shortcuts” and *nix terminology is “symbolic links/symlinks.” The fact that Windows finally went with the standard *nix terminology is a mild source of surprise.