It's interesting idea and easy to understand, but i don't like it due to these reasons.
1. It's a hard-fork, which unlikely to be accepted by Bitcoin community and developers.
2. Additional technical complexity on protocol level. I prefer either block size increase or LN software improve how they handle inconsistent TX fee rate.
This seems like it would open an avenue for a significant attack. Couldn't a malicious party "Reserve" space as much as possible every time fees are low, and then after a few years "Redeem" all the reserved space all at once in a HUGE block?
Using this to attack Bitcoin would be equally expensive than a normal spam attack, so I think the reservation of space itself is not a vector here (i.e. you couldn't make Bitcoin unusable). I'm unsure if the huge block in the future could be a problem though. Perhaps this could be solved with a hard block size cap of e.g. 2x the current max vByte size. This means there would be additional space for "redeem nonce" transactions per block, but a limited amount.
But that would kill the point of OP's idea, since people/group who have "reserve" still compete in terms of TX fee rate.