Maybe your right? Please point me to a double spend.

Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.

But usually one of the forks gets chosen by consensus right? And after 6 of so confirmations it is extremely unlikely to change.

When this thread was opened there was a bug (or bug fixed) with the latest version of the software which means that the new version of the software chose a different branch to the old, which is a very different and horrible problem. IIRC the developers told people to downgrade to the old version and the associated fork became the chosen fork, and thus losing transactions made in the unchosen fork.

Hammer me if this isn't 100% accurate but I think it is the gist.

Usually forks are OK and get resolved. This thread is about a different 'hard' fork cause by software issues.

Yes, the failures in the automated alert systems have been addressed, so services should be able to disable themselves when a long fork is detected:
https://github.com/bitcoin/bitcoin/pull/2658

What is your definition of double spend?

Are you including operator error and self-inflicted (ie. allowing 0-confirmations)?  The network (and access) isn't always fast enough for every use case either.

Which is what happened in March, 2013.  If you were using the v0.8 client there was a transaction that had more than six confirmations but later the fork which pre-v0.8 clients were mining surpassed the one the v0.8 were using and that transaction became invalid.  What happened was a user noticed the fork, created a new transaction that spent the same funds, used a custom client that repeatedly broadcast the double spend attempt and eventually that new transaction got included in the pre-v0.8 blockchain fork.

So yes, a double spend of a transaction that had six or more confirmations on what was at the time the longest chain is something that has occurred.

The gist of the problem was that miners starting up with the v0.7 client had an empty memory pool and thus no knowledge of the transactions that had already confirmed in the blockchain fork mined by the v0.8 clients.  So then it simply is a race -- whichever transaction (of the two that were spending the same coin) that reached those miners first is the one that was being hashed.   For that specific weakness, there are solutions that had been discussed but not implemented as far as I know.  For instance, when the miner is shut down the unconfirmed transactions in the memory pool could be written to the filesystem and then those transactions get loaded first when the miner starts back up.   That would likely have made the result of that March 2013 fork be that no double spends had occurred.

Five years later, no block explorers still show Macbook-air's original transaction that had gotten double-spent after the block reorg.

Here's a list of seven transactions that (allegedly) had been confirmed on the v0.8 side of the fork, but were later double spent on the v0.7 side of the fork.
 
12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195
cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af
7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96
355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e
b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a
138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6
a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90

Source: https://pastebin.com/raw/wctJU3Ln