Your program must be really small and scoped for this to make sense.
Also, kudos for providing so many corner cases to avoid that are non-trivial to formulate.
It feels like one of those "it's not impossible to do right" cases.
I'll just cite one evaluation point from the post:
> It's extremely easy to use incorrectly.
> Your program must be really small and scoped for this to make sense.
to me suggests that it's not really global state if your program has to stay small and scoped. In a sense, your program has just become the context boundary for the state, instead of a function, or class, or database.
I realise that this line of argument effectively leads to the idea that no state is global, but perhaps that gives us a better way to understand the claim that 'global variables can work', which they undoubtedly can. It's fine for a program (or a thread, as in the original article) to be the context which bounds a variable's scope.
It's still possible to wrap all that as nested state in a single global, and it works just fine:
https://github.com/floooh/chips-test/blob/613dbfe907104f4110...
That's a single mutable global with all application state, but inside that global are nested structs and the code working on those structs takes essentially a 'this' pointer. This approach works well since it enforces a strictly hierarchical code and data structure with a single root-struct (and also a single root-source-file) at the top.