It is mathematically identical in pretty well all respects

Yes it is - as per those Turing equivalence theorems, all code is identical, regardless of language or algorithm.
[/quote]
I don't see how this relates to our discussion.

void Gun::Update(bool triggerActive)
{
if(triggerActive)
{
Fire();
}
}

Enter IOC/DI...
class SceneEntity {
GlobalFlags * pFlags;
}

class Gun : SceneEntity {
...
void update() {
if (pFlags->triggerActive) Fire;
}
}The pFlags gets passed in during construction, most likely inside a factory.
[/quote]
This illustrates what I mean. Passing in a set of global flags to a Gun class, so the Gun class now has a member pointer to a global variable, provides little or no benefit to your program. The core problem, the fact you're accessing global state in an inappropriate context (as opposed to 'inappropriate manner', by accessing that information through globals), has not been resolved

Most notably, it changes precisely nil in terms of thread safety when we're talking about references to global data, an often harped on about benefit of not using globals (which I've yet to understand)

Well:class DistributedSim {
threadlocal<GlobalFlags> flags;
Gun * g;
DistributedSim() {
g = new Gun(flags);
}
}
Now I can run multiple simulations inside same process without any lock contention.
[/quote]
You could have achieved the same outcome using threadlocal<GlobalFlags> g_flags. I'm not advising that's the way to go, I'm just saying eliminating the global instance does not, in and of itself, fix any multithreading issues. It merely prepares the framework to allow multithreaded behavior, but without actual changes to implement the thread safety, nothing changes.

Finally, IT industry concluded in 2002 that singletons spell death of project maintainability. And IT isn't known for being at bleeding edge of experimentation. Computational performance was never relevant to them (except for that certain bug they found in VMs), but performance and scalability of development was. During the next year, everything shifted to IOC/DI container or dynamic languages. None of this can be proven mathematically, but falls under soft observations. It just works better in practice.

Unsure what you mean by 'IT industry', however in terms of such a conclusion, at best, they could conclude poor use of singletons is a significant barrier to project maintainability. At worst, such a statement is an outright falsity, as some singletons never need to be removed, thus endure the complete project lifecycle.

a singleton in mostly every os of today: the mouse.

if it wouldn't be, we could plug in more than one mouse and use more than one cursor (similar to multitouch) since years in every os. and heck yes, i would. sadly, at some point we got limited to only one device ever, as no one ever needs more than one cursor. and the whole os' got designed around it.

now that we can have multitouch, the os' are still not designed for it (at least win7). the result: i can not, for example, drag multiple windows independently around the desktop at the same time.

it's a simple example of potential that was there since years and never got exploited just because we where all fixed on "there can be only one".

Even though I don't like singletons particularly, this is a pretty good example of that you can't predict _everything_, requirements change.[/quote]

/dev/mouse1, /dev/mouse2, /dev/mouse3, ..., /dev/mouseN. Same for any other hardware resource.

It's "one mouse should be enough for everyone" that is unusual.