I am confused by your comment but this may just be me missing the joke. I can be a bit dense at times, so forgive me if this is the case. Rather than trying to engineer an optimal layout for storage proof construction, why not allow the proof of a single storage slot to be sufficient? If you have all keys added to the system be appended to a Compact Sparse Merkle Tree (CSMT), and also maintain an append only revocation CSMT, you can then build a height two normal Merkle Tree of those two roots. In this way you can easily describe the state of the system by proving one hash and then providing proofs of inclusion/exclusion for the CSMTs. It is important to note that the revocation tree has nothing to do with expiry, or at least it shouldn’t since building it otherwise would create the problem of, “Who pays for the gas to add elements to the revocation CSMT on expiration?”. This is basically the idea behind Certificate Transparency Logs as described in Google Trillian Verifiable Log Backed Map. See the Deposit Contract Formal Verification(See 1 below) for a description of how a CSMT can be built in chain. If you have not read Peter Gutman’s, “Engineering Security”, you may find it an interesting read.
1: Since this is a new account, I can only link 2 articles. Here is the url for the formal proof. github-DOT-com/runtimeverification/verified-smart-contracts/blob/master/deposit/formal-incremental-merkle-tree-algorithm.pdf