Interesting proposal! To piggyback on @Julian’s comment, Relay Block Merging could be extended to support a less universal version of such an encrypted mempool. This maintains protection against builder frontrunning, at the cost of limiting the set of key share holders to builders and relays.
Specifically, builders and relays could hold key shares and lazily pass forward decryption shares with the payload. In this way, no ~significant additional latency would be introduced.
At the relay merging stage, the decryption shares provided by the builder and relay could be combined to append the decrypted transactions to the block. This prevents builders from frontrunning and only maintains trust in relays, which is an improvement over the status quo.
A more advanced setup could allow k-of-n shares to be combined, where the set of relays holds enough shares to reach the threshold. In this way, the transactions can be decrypted without the builder’s share, addressing the free option problem. A simple way to implement this is to use the channel used for relay constraints sharing.
Overall, the main advantages of such an out-of-protocol setup are that it addresses frontrunning risk, and is doable today. The big downside versus a native implementation is that we maintain the relay as a trusted party.