So it sounds like multiple snapshot tasks with the same name but different frequencies should work fine.
In my opinion they do not work fine. In fact, if you start from the principle of "snapshots are sacred and should be preserved with care", then using the
same naming schema for
different snapshot tasks with
different expirations (on the same dataset) can
risk destroying your long-term snapshots, which you might
assume will be "safe" (unless you intentionally delete all of them.) I supposed it's the nature of zettarepl and how it is based on parsing through names (rather than using a companion database or catalog with a separate index.)
You see the above screenshot? Notice both tasks use the same naming schema? They are both auto- (not differentiated as auto-hourly-, auto-daily-, auto-weekly-, auto-monthly-, auto-yearly-, etc.)
If after much time has passed, and they populate with many snapshots, the user's assumption is that the snapshots created by each separate task will be
preserved based on
that task's expiration cycle. Yet simply pausing the long-term task (as seen above by unchecking "Enabled") will doom those snapshots to be destroyed, the only ones surviving being those that are lucky enough not to overlap in timestamp name with the more frequent snapshots in the other task(s).
The same risk applies to renaming the task (as the previously created snapshots using the older naming schema are no longer under the newly renamed task's "protection".) And of course the same risk applies to removing the task outright, as the previously created snapshots that fit a certain pattern in their name will be destroyed by the still-existing and more frequent task.
So for example, let's say you only have two tasks for the same dataset, and they use the same naming schema, but differ in frequency and expiration.
- tank/playground, auto-%Y-%m-%d_%H-%M | frequency: hourly | expiration: 1 week
- tank/playground, auto-%Y-%m-%d_%H-%M | frequency: weekly | expiration: 1 year
While they are both "Enabled", there's going to be overlap with certain snapshots that the user assumes will be "protected" for 1 year. For instance, after a year passes, you will have a
bunch of snapshots from a week ago, yet only about 52 of them beyond that point, all the way to a year in the past.
Yet, here comes a "whoopsie!"
Your
weekly snapshots are taken on Sundays at midnight. They might look like this:
- auto-2021-07-11_00-00
- auto-2021-07-18_00-00
- auto-2021-07-25_00-00
Those names also collide with your
hourly snapshots. After all, if you didn't even have a weekly task, those names would have existed at some point since "00-00" is part of the hourly pattern.
Guess what happens if the user decides to "pause" his weekly snapshot task by unchecking "Enabled"? (Or rename it, or even just delete it?)
"The snapshots that my weekly task already created, of which I have a year's worth, should be safe, right?"
zettarepl still runs the hourly task (that uses the same naming schema of "auto-") and will destroy all those snapshots from a year back because they happen to have "00-00" in their name, which fits the "hourly" pattern. These unfortunate snapshots no longer have the protection of the "unchecked" or "renamed" weekly task.

(See below how to safeguard these long-term snapshots.)
Now re-visit the scenario above, except with different naming schemas:
- tank/playground, auto-hourly-%Y-%m-%d_%H-%M | frequency: hourly | expiration: 1 week
- tank/playground, auto-weekly-%Y-%m-%d_%H-%M | frequency: weekly | expiration: 1 year
Can you see how regardless of whether or not the weekly task is temporarily disabled, the snapshots it
already created will remain safe since there is no possible collision of names?
EDIT: I want to reiterate that I agree with
@gary_1 and
@Forza that it would be better if we could specifiy a
single task, which takes frequent snapshots, that are "dynamically pruned" as time goes on, which results in what some call "staged" or "smart" expiration schedules. The example you posted from Borgbackup illustrates this feature, as does other backup software.
Perhaps this is not possible with zettarepl / parsing names, as it might require a database with its own index to keep track of everything?