extend retention policy to take into account the number of snapshots and/or time of last successful run

If I understand correctly, setting, for example, `24h` as part of a retention policy will preserve at most one hourly snapshot as far back as 24 wall-clock hours (not the 24 most recent hourly snapshots). As far as I'm concerned, that's the right thing to do in principle.

Now consider a source turned off over the weekend. Wouldn't btrbk wipe all the hourly snapshots on its first run after the break? So if I did something stupid on Thursday and notice the on Friday, I get fine-grained rollback, if I botch it on Friday and notice on Monday, all I get is a daily, even though subjectively it's the following workday in both cases. (Same for dailies and a longer holiday, etc.)
I'm not sure I feel comfortable with that, i.e. btrbk treating time passed with regular successful runs and time passed without any the same. I'd prefer to to keep the most recent 24h of actual work done, for some subvolumes at least, to have the option to "stop time" during downtime, maybe taking the timestamp of the most recent snapshot into consideration, or simply something like `24h+` "keep hourly snapshots 24 hours back, but at least the 24 most recent hourlies" and so on.