Therefore, a CLI command could do the job.

Requirements:

be able to render a plan of what it is going to do
be idempotent (i.e. work even if it crashes in the middle)
- allowed to make the assumption that the original job name has not yet been reused
3-step interaction
- persist somewhere that the job is being renamed
- make sure the job is not running in the daemon (and won't run on restart)
  - sufficient to kill the daemon and have some kind of disabled blacklist somewhere
- do the idempotent rename operation(s)
- tell the user to
  - rename the job in the zrepl.yml
  - invoke a zrepl rename complete OLDJOB NEWJOB command that
    - un-blacklists the old job name (making it available for a new job definition)
    - re-starts the new job name (pbly ok to just restart the daemon, or tell the user to do it)

Additional thoughts:

we could also think about having job GUIDs and only aliases to refer to jobs, but those GUIDs would also need to be stored in some kind of database etc
- design proposals welcome, in the meantime, a rename command is pbly good enough