I haven't read the rest of the thread but the above is the primary problem, and is common whenever we hardfork because we get long minority chains from delegates who haven't updated.
There is also a second problem where blocks after the hardfork are not necessarily invalid for old clients. So they might upgrade after the hardfork and if they don't reindex, they will have an inconsistent state but cannot tell until they finally start rejecting blocks.
It seems like we can mitigate the most common issues by a combination of:
Force all blocks after a hardfork to be invalid for old clients
Always reindex for hardfork releases
Always release a version with a checkpoint right after the hardfork as soon as possible. And force a reindex on startup if any checkpoints dont match the current state
addnode 22.214.171.124:1375 delegate.nathanhourt.com at
addnode 126.96.36.199:1375 fubly
addnode 188.8.131.52:1375 liondani
addnode 184.108.40.206:1375 wackou