Regarding franky1's orphan risk because of rescanning nodes: I think there is no other way than what aklan said, to store the maxblocksize changes in the blockchain, so the nodes are aware of the changes when they rescan. There would be perhaps another possibility - to make a conditional decision ("if CheckedBlockSize > ActualMaxBlockSize and CheckedBlockHeight < (ActualBlockHeight - 2016) then AcceptBlock") so nodes can accept larger blocks when they rescan and are more than one difficulty period under the actual block height, but I don't know if this introduces new attack vectors like nodes passing a fake ActualBlockHeight value.
There must be a simple fix, since (at least as far as I remember seeing) no one raised the issue when BIP106 was originally proposed, or, more particularly, when lukejr proposed
reducing the blocksize. I'm sure a dev wouldn't have made a proposal with a gaping hole in it. Someone would have voiced concerns well before this point if it were a showstopper. Obviously this wouldn't work as a soft fork, so if all nodes are upgraded, it stands to reason we can tell them not to reject blocks that were valid at the time.
As for blocks being newly appended to the chain at the moment of a reduction, miners could voluntarily operate a soft cap of .01 base and .03 witness under the current threshold if they wanted to play it safe. Effectively they could operate two weeks in lieu of the actual limit. Plus that's only an issue if the blocks are full to the brim at the time.