I personally wouldn’t recommend that approach (as Martin indicates, it’s a bad idea). However…
If you define a variable in a module:
$MyVariable = 'whatever'
That becomes a global variable since modules are loaded into the global scope. There’s no reason to use $global. And, when you unload the module, the module-level variables get removed automatically. This is how you can create module-level “preference” variables. But there’s no reason to use the $global modifier; that can really easily lead to a lot of scope confusion, and it can leave a messy global scope after the module is unloaded.
You would need to load the module first, and then set any variables that the module defines - and that’s a much cleaner, easier-to-debug, and easier-to-maintain approach, if your choice is to create preference variables. I’ll note that the module will automatically export those module-lavel variables as “global” variables, unless you’ve explicitly used Export-ModuleMember in the module. If you did, then you must use Export-ModuleMember to also export the variables you want “exposed.”
As a general practice (there are exceptions, but not a ton of them), you want to try and avoid scope modifiers like $global. They make it easy to be messier, and messier makes debugging and maintaining harder.
Sorry, Martin - totally not trying to beat up on you, I just wanted to offer an alternative that fits a little better with debug-and-maintain practices. Hope you don’t mind. The $global thing has been giving me a lot of grief and clean-up work lately, and it’s getting late on a Friday! And, of course, you already pointed out that it’s a bad practice!