I know it’s been mentioned that Picard is a verification and customizable organizing tool, not a library manager. I get that 
Though I still wish there were a way to keep track of what items have been saved somewhere along the line that satisfied the needs to indicate ‘complete’. But that could be a rabbit hole of it’s own. Though sort of like .bash_history, let it keep the ID of something thats been completed previously. Regardless of the quality, file formats, etc. Again, not a library manager, but as an organizing tool, giving me a way to be able to separate the already haves, (okay, semantics, call it already been run through this mill in some form or another, capice? 
Like … if $HasBeen() then… which would now give a flag option for scripting these files separately. e.g., put them in a different path. So I could then have my script place them in path/tree just like incomplete, completed, and now… duplicate, or whatever the user wants to call it.
It would mean auditing against another file at processing time, if it’s used, and yes, that could mean another tick box en/disabling/clearing some file.
But it could also enhance the organizing flexibility of Picard quite a bit.
…and along those same lines, even in the same session, if it’s going to write a file that causes the need to have an incremental number appended, put those there too.
Which then brings up, I know. What about when yet an additional comes along. A 3rd, 4th, 5th… extreme examples, but it does happen when you’re trying to unscrew 20+ years of the iTunes directory ya started when it was called SoundJam.
So, on additional duplicates, do what it does otherwise does now. Appends an increment to the file name, and moves on.
Then if $HasBeen() isn’t part of the script, nothing changes. The incremented file happens in the same location as the original. If logging said file is disabled, then it would mean that $HasBeen is just ignored. Carry on as intended.
This would allow one have ‘management’ capability in the most basic form possible, while handing off the actual management to the user to decide how to deal with it.
Hey, this means I already have this, (because at some point I processed it, and have since moved it to the file tree for the music player) … and since I have this again, I can choose to ignore, compare, see if the more recent result is more preferable over what is already there… (Note I didn’t say ‘better’, that’s a user decision.) Better may mean file format, track length, or maybe ‘better’ is a crappier qualify version because you are making an example of the worse vs. the best. Who cares. Picard doesn’t.
I would imagine that at the very least, adding a variable is probably something that needs to be done in the core, in order for it to be usable in a script. Then there is that log file updating. But I’m sure there’s plenty of log files/options for log files to be updated now, so it’s not any new functionality infrastructure wise. Just another call, with another set of variables sent to some library that takes the “Do this” variable, the “This is the data” variable and writes it to the “This is the file name” variable, that itself could be hard coded just like the option of what to name cover art.
If only my scripting skills were a bit more than in the well planted range of “Enough to Get Yourself in Trouble” category. I loved flow charting in high school programming class in those days on that DEC with the neato stylish Bertone terminals. I can follow along in the code to see -what- it’s doing and document things quite well. I just step all the hell over myself trying to create from scratch and anything substantial change wise is a very in-efficient use of my time. Mostly syntax related screwups, as I do a bit better swiping bits from here and there, editing existing stuff, merging functions together.
Enough rambling on, before whoever is reading this forgets about what I first talked about / asked. 