The another fix (preventing PastRateActualSeconds to go to 0) takes care of another attack vector. Here is a short explanation of the attack:
1. generate a block 2 weeks to the future. You cannot publish it, it is not on current time window.
2. Start generating blocks with the same timestamp (ie the moment 2 weeks in the future)
See what would happen: after there is PastBlocksMax blocks in the private chain, *the diff would not change* at all!
That would mean you have 2 weeks to generate blocks with 0 difficulty. With decent hashrate, you easily get 1 block in a second. In 2 weeks you get 1209600 blocks.
When that 2 weeks has passed, what would happen to the blockchain, if you suddenly publish 1209600 perfectly valid blocks? The whole network would be doing nothing but checking those 1209600 blocks... and finding nothing wrong with them. That would be the end of the coin.
First, an attacker still needs to exceed the cumulative difficulty score of the original chain. Second, there must not be any checkpoints on the original chain for those 2 weeks, neither hard coded nor synchronised. Third if the second is true, this is a huge reorganisation which won't pass unnoticed and a smart developer would secure his chain with a checkpoint immediately, release an updated client and ask the community to upgrade.
EDIT: Actually, it *is* prevented somewhere else. One can generate only 5 blocks with the same timestamp.
Median of 11 is 6 blocks. Although AUR has changed this to median of 3 which is a bad idea actually.