These are my thoughts...
Automated backup would go about doing its thing, creating files as it does today. It could be tweaked independently as per JR- or user-needs.
The problem with today's automated backup that users want to resolve, is a) its not predictable, b) it is not timely, and c) it is not automated. Users know when their backup software runs; forcing a backup just prior to that run minimizes the potential size of change-set loss. Otherwise, a backup might be days old, and quite stale.
The backup file name created via MCC should not use the same name space, so that there are no namespace conflicts. A user knows the backup created via MCC was created via the most recent MCC command (i.e. probably the one just executed in the script). Just knowing the simple path/name is sufficient to reference it.
By using a simple, unchanging name of the MCC-driven backup, a script can force an *immediate* backup, and then reference the backup zip file easily (mutable file names are harder to determine "latest" in a directory full of similar files; it is much easier for the script writer to tack on a date or qualifier to a non-mutable file name).
There can be multiple backups on the same day when a user manually backups a library on the same day when the auto-backup ran. Currently, the user needs to enter a new file name via dialog. If the user is supposed to always overwrite, why present a dialog at all? If not, there will be multiple backups for the same day.
Or if the MCC backup was run more than once / day. With the dated naming system, MC or the user must manage previous backup files. And this defeats the point - the point of MCC backup is to obtain a single backup, now. It can then be used, eliminated, or forgotten with no consequence.
Some people make lots of changes and maybe want, say, 2 backups per day. I do this frequently during, say, testing out some new feature or idea. I never overwrite today's early backup file, as that is another layer in the safety net.