To prevent multi-slot MEV the builder of block N should not know whether it will also be the builder of block N+1.
A potential way to do so is to do a MEV-Burn and appoint the execution proposer of slot N in the beacon block of slot N (assuming beacon block and execution payload are separated). That looks a bit like the following.
The problem is that no one knows who will be the block N execution proposer in the time interval after the execution payload of slot N-1 is released and before the beacon block of slot N is released. That removes the possibility of providing preconfs during that time interval.
If we do want to have preconfs and prevent multi-slot MEV, we would need to generate randomness just after the last execution payload. It may look something like this
I wouldn’t know how to get this to work in the context of Ethereum though. At first I thought that it would be possible to use an encrypted mempool and then generate randomness based on e.g. the hash of the post-state root given that transactions are encrypted after block 99 in the image. Together with @b-wagn I explored encrypted mempools but they do not have a clear solution either.
If you could explain a bit more what you mean with the WHISK-like techniques or RANDAO that would be very nice!