I think I've discussed this type of concept previously somewhere but cannot find a link to where.

Largely, I think the following:

1) This doesn't reduce burden of maintenance and risk of consensus split, it raises it:

   A) as we now have a bunch of tricky code around reorgs and mempool around the time of rule de-activation.

   B) we need to permanently maintain the rule to validate old blocks fully

2) Most of the value of a 'temporary soft fork' is more safely captured by use of a CTV emulation server / servers, which has a more graceful degradation property of the servers simply shutting down and not authorizing new contracts, but funds not being vulnerable to theft. The model here is trust, as opposed to a timeout.

   2A) The way I implemented the oracles in CTV was such that, if we wanted to, we could actually soft-fork the rules for the oracle's keys such that they would *have to* only sign CTV-valid transactions (e.g., the keys could be made public). Pretty weird model, but cool that it would enable after-the-fact trust model improvements. This could be generalized for any opcode to be emulator -> emulator consensus guaranteed -> non signature based opcode.

Although I will note that I like the spirit of this, and encourage thinking more creatively about other ways to have temporary forks in Bitcoin like this.

Best,

Jeremy