Global fields are a lot like user session variables. So I guess you won't see that often in DBMS, but it is something you should be able to find in other environments that take in charge the user's connection to a DB backend.
They were implemented as fields in FileMaker back in the days because it was pretty much the only mechanism available to define anything. It stayed this way for backwards compatibility purposes. If it was to be implemented again today, I'm not sure it would take the same shape (in FileMaker). That would be an interesting question for one of their product engineers.
Trying to understand better here: I understand the backwards compatibility thing but when creating a new solution why would I choose to use global storage field rather than a $$ ?
to use it in relationships in order to have many portals, in a dashboard for example. Global variables are used for scripting etc you cannot base a relationship. So with global fields you can "connect" every table in a given layout... or in an import you can't use a global variable but you can set a value in a global field....
In the context of a new solution and a decision between a global field and a global variable, here are some elements to consider:
Will you need the user to interact with the variable with native UI? If so, the field is the right option for that (entering data directly in a field, choosing from a drop-down menu). Examples include temporary screen containing global fields to validate the user input before it is, making a selection in a screen before running a report, ...
Will you need the value in your global to be a predicate in a relationship (left-hand side)? If so, you are best with a global field. You could create an unstored calculation that will point back to a $$var, but the relationship is less likely to be aware of a change of value and you will need some mechanism to refresh it.
Do you need the global to be impacted by something happening in a calculation? Using a let statement, you can alter the contents of a $$var from any calculation (layout objects, custom functions, ...). Global fields can be read from a calc, but cannot be written to. Some consider them less safe/secure for the same reason.
Some people do not like $$vars because they clutter the data viewer
For imports, you can use a global field in the import field mapping or you could design an auto-enter calc making use of a $$var (or a global field or even a $var if the import is scripted). You can apply auto-enters to many fields. Field mapping is one-to-one only.
You can share global fields across multiple files by including a TO using an External data source from the original file. $$vars cannot be shared across files. To retrieve them, you need to call a script of their native file that will return their content via script result
if you need to hold container data, you should favor using a global field. You could encode to base64 and hold it in a $$var, but the display won't be as interesting.
I must say that in my 4 years as a FM citizen developer this is one of the most useful thread about global storage fields I’ve encountered.
So in line with OP question, what we are trying to determine is whether another product/platform has constructs (not variables) to store data (field, cell ...) that has such global storage and functional characteristics...
Now that I read the update in the original post, security is also a difference:
You can set read / write limitations to the global fields, not so much to global variables.
Fun fact, the "read-only" privilege set can write to global fields. Duplicate that privilege set and the resulting privilege set now prevents writing to the same global fields.
Sorry if this is drifting away from the originally intended topic. @Cecile generally has a good judgment about where stuff belongs and when to split if necessary, I'll defer to her.
You are right, I omitted that hack. For the comparison with a $var, someone could use while() or customList() to generate a similar list. Or just loop.
to setup a while function or a loop command requires more coding then the 'low-code' SIMD (single instruction multiple data) command .. amazing feature for global - no locking ..
Agreed to, also, very counterintuitive. Someone else looking at the code not being aware of this behaviour could think the code is mistakenly targeting the wrong field. The other methods may be more involved, but can be read more easily by another developer than the original developer.