Statistical

While dropping to v0.7 was a method to resolve this in a manner which protected v0.7 users it wasn't necessary. Miners could have continued to mine v0.8 chain. Transactions from the v0.7 blocks would be included in v0.8 blocks.

Users could be warned to STOP using v0.7 and upgrade to v0.8. The advantage of downgrading it is resolve the situation quicker. Far easier to get a half dozen mining pools to switch to v0.7 then get thousands (tens of thousands) of users to upgrade to v0.8. A v0.7 user who followed the warning and stopped engaging in transactions either until v0.7 was the longest chain or until they upgraded to v0.8 was not in any danger. Existing transactions flowed across both halves of the split.

Not really. For example if 51% (or even 99.99999999999%) of miners decided they wanted to go back to 50 BTC block reward (or even a new 5,000 BTC block reward) that would simply create an incompatible fork. A fork which would most likely be promptly rejected by the consensus of users, merchants, exchanges, and service providers.

One can't simply force a change to the rules. All you can do is make a hard fork in the network. If nobody adopts your hard fork well you can keep mining worthless coins but people can continue to use/mine the existing fork.

Bitcoin is highly resistant to change (almost to a fault). It is a common myth that the person who controls the majority of hashing power can change the rules.

The fork was at the block level not transaction level.

The transactions are on both chains. While they may be in v0.8 blocks and still unconfirmed in the v0.7 fork they do exist in the v0.7 fork. The only transactions which couldn't exist in the v0.7 fork are those generated in "v0.8 only blocks" and those are hard locked by the protocol for 100 blocks.

Had both halves of the fork existed for more than 100 blocks that would have presented a more serious problem. This is why the stakeholders (exchanges, merchants, miners, and developers) moved quickly to halt transactions, warn users, and move to the v0.7 version of the chain BEFORE one chain got more than 100 blocks from the fork point.

> If this were an unlucky edge case, I could understand. But it seems like they allowed larger block sizes without testing them on pre v0.8 miners

That is not entirely correct. Multiple large blocks were tested on v0.7 (and older clients). Blocks up to the 1MB hard limits were validated and relayed by older clients.

The "problem block" in particular wasn't rejected due to simply being too large. It was somewhat rare in that it exceeded the number of low level locks available to v0.7 clients. It had a large number of transactions with a large number of inputs and outputs and those happened to have a large number of compressed keys. Without using a high number of compressed keys it wouldn't be possible to have a block with this number of inputs and outputs in the 1MB limit.

Granted in hindsight more testing should have been done but it wasn't like nobody said "hey we should test large blocks, nah I am sure it will be fine".