Let's assume for a minute that your theory is true, and that actual nodes on the network would not accept this new, valid, and longer block chain.
That on itself would be a bug. Maybe it isn't obvious for a 5-block reorganization, but if it was a 2-block deep one (which actually occurs in practice), your argument would be equally true. If there was no means to accept a 2-block deep reorganization, nodes would be stuck in their shorter chain. This is actually exploitable too: someone may intentionally try to get you in such a state, as you will not see new payments on the chain that might conflict with a payment the attacker is trying to send you.
This is true for any depth of reorganization. If we don't accept 12-block deep reorganization, the network would remain in a very sore state if there would ever be a few-hour partitioning of the network. Being able to accept the longest valid chain under every condition is absolutely required for making Bitcoin converge.
So: we need a mechanism to reorganize pretty much any depth. How it is accomplished changed in Bitcoin Core 0.10 with the introduction of headers-first synchronization.
Before 0.10, the attacker would broadcast B11' first, which the victim doesn't know about. It will do a getblocks message to request the hashes of blocks between B5 (using a block locator) and B11'. When it receives these hashes, it will download them one by one using getdata, see they have a missing parent, place them in the orphan pool (the set of blocks without known parent), and when they're all received, notice that they connect, and switch to it.
Since 0.10, the attacker would inv B11'. The victim will use a getheaders message to request the block headers between B5 and B11' and getdata for the block B11' itself. When the headers arrive, they are validated on the fly (in order of increasing height, so they always connect). By the time B11' arrives, we already know about its parents, and know that (assuming the parents are valid) this will in fact be the new best chain. We will then start fetching the actual blocks B6' through B10' to fill in the gaps, and when they have all arrived, switch over to that chain.
Sidenote: Assumption 2 seems irrelevant. If M controls 99% of hash power, it surely could run hundreds of nodes all around the world. It can always decide how many to use depending on its needs to do malicious acts. – Jannes – 2015-10-14T11:17:09.127
It still can't use these hundreds of nodes to change what other nodes think. – Pieter Wuille – 2015-10-14T11:25:48.137
If a Bitcoin node could know for certain which is the last block, the whole multiple confirmations thing wouldn't be necessary. – David Schwartz – 2015-10-14T11:32:16.140
@pieter that's why i said irrelevant: doesn't matter either way. – Jannes – 2015-10-14T11:50:37.883
Jannes: so you're saying that an attacker with an equal amount of money but without large hash power could do the same thing? That is incorrect. The number of nodes does not matter, but the hash rate does. – Pieter Wuille – 2015-10-14T12:13:09.507
@PieterWuille ehm... misunderstanding here. Assumption 2 says "relay power" i.e. the number of nodes the attacker runs. I'm just saying it doesn't matter whether he runs 1 or 100 nodes for his attack to succeed or not. It's irrelevant. – Jannes – 2015-10-14T12:47:53.560
@Jannes My apologies! I missed that you were talking about assumption 2. – Pieter Wuille – 2015-10-20T13:35:37.970