The easiest part is to increase interval between blocks 51-fold. Then to make majority of delegates to sign every single block together. => 1 confirmation is as reliable as 51 confirmations in old design, but as a free bonus you are now protected against network fragmentation because if you don't see the next superblock for a long time then you are eclipse-attacked or delegates can't find each other.
While I don't think the attack you are suggesting is a serious issue and I don't really see how your suggestion
prevents the 51+ delegate collusion attack, I have
proposed something similar to what you suggested but without changing block interval requirements. The idea is that in typical scenarios, we should have greater than 80% delegate confirmation of the state of the blockchain within 20 seconds.
Next step is setting a requirement to "refresh" votes every week with the quorum set to 51% of the stake. If less than 51% of the stake takes part in the voting then network stalls automatically. => DACs should be happy + employees can't abuse their power.
It is already possible in theory to measure how much of the stake has participated in voting where the votes are not older than a given time. I don't think there is any reason to make this a hard requirement in the blockchain. If a user feels uncomfortable with the percentage of the stake that has updated their votes in the last month, for example, or especially if their vote update transactions are being ignored by the delegates, then they could perhaps start communicating their suspicions with others and start organizing a potential hard fork. In the forked chain (I will call BTS'), which snapshots off a recent block in the main chain, they can all vote on whether their vote update transactions have been filtered by the delegates in the main chain and that they wish to start with a new clean slate of delegates. If you reach some quorum on this fact (+ the new set of 101 delegates to take over the new chain) on that new chain (say >50%), then the stakeholders will initiate yet another hard fork of the original BTS chain.
The second hard fork is to incorporate in the snapshot all the updates to stake and BitAsset ownership during the time between the first snapshot and the second snapshot, which should be very soon after the point at which 50% consensus is reached on the first fork. Then on this second forked chain (BTS''), a quorum of 75%, for example, would be necessary for the chain to begin as the new BTS and for the original chain (BTS) to be considered an invalid fork (and hopefully merchants and exchanges will also agree to this new consensus) . People will dump the stake of the old chain (killing the old chain's market cap) and start using BTS'', now rebranded BTS, of the new chain like the real BTS. Any transfer on the original chain after the point of the second snapshot
might be void (double spend), but the users should have likely stopped transferring stake on the original chain, just to be safe, when they realized that 50% consensus was reached on a fork.