Things are clearer now, but that leaves me confused about a few things still.
* Is there some invisible synchronisation going on every time I write
top-level variables, or is it unsafe? If it _is_ unsafe, I would have expected
a warning.
* If "every top-level variable ... is global" and "{.global.} ... promote
locally-declared variables to the global scope", then why is adding {.global.}
to top-level variable legal? While it obviously doesn't do harm, if the
compiler had told me it was "pointless" as a warning, I would have probably
realised that I got something wrong...
* If default allocation (new) is thread-local, why make top-level variable
global? That feels "counter-intuitive" somehow; I would have expected either
everything to be global by default, or thread-local by default (which is
obviously why I was confused). And if writing to top-level variable is not
synchronized, and therefore unsafe, doesn't that make a good case for having
them thread-local by default? Then the required {.global.} pragma would be a
strong hint that access from multiple threads should be guarded.
I'm not saying it's a _bad_ design, but I'm saying it's a _surprising_ one.
Top-level variables are normally global in the languages I know. But that
obviously works together with allocation also being global as well. So I guess
I was imagining that if allocation was local (by default), then top-level
should be local too, so that it "fits together".
