@rchiav: Thank you for your thought-provoking comments. Being forced to think about something can be painful.
I had a similar set of exchanges when I asked about how to make calibre preserve my preferred author name ordering (last, first) when generating author_sort. To distill the responses harsher than they were, what I was told is that calibre works the way the developers want it to work, and why should they take time to build something of no interest to them? This attitude is eminently reasonable. Why should someone donate time and effort for something s/he won't use? Well, the problem annoyed me enough where I decided to look into fixing it. Being semi-retired (and soon fully retired) I had both the time and the desire to learn something new. (If you are curious about who I am,
this is my home page.) Perhaps you are in the same situation, having desire, time and inclination.
There is a
nice page in the manual that describes setting up a development environment. Unfortunately, that is the easy part. Calibre is large and complex, is built from large and complex tools, and (naturally) reflects Kovid's style of doing things which often doesn't match mine. It took me some days to be sure that a 5-line change to solve my problem was the right change. However, in the end I got the functionality I wanted, so it was worth it.
Since then I have implemented more functions for my own use: tags with exact matching (released), an added GUI column that indicates whether a book is also on a plugged-in device (not released - someone is implementing it differently), and now saved searches (will be released). My next project will probably be tags-as-columns, assuming that Kovid agrees in principle to release it (I haven't asked him yet).
The point of this screed is that if you can't convince someone to build what you want, 'use the source, Luke'. In my experience, Kovid is very open to changes, and will discuss alternatives if what you want to do doesn't fit into his model or future plans.
@Kovid: what about building a 'job builder' that would permit a GUI user to run groups of 'batch' commands on a selected set of books. What I am imagining is something that provides a subset of that provided by the command line calibredb, ebook-meta and ebook-convert commands. As calibre already has a parser, setting up a batch language wouldn't be too difficult. One would probably also want a way to select a set of books -- to run a search. To use it, the user would save the list of commands under some job name, and then run that job whenever wished.
What I don't know is whether the threading implied by the job mechanism would break things. I can imagine lots of ways that it would. If it does, then the job would need to run in the foreground. That would be mildly annoying, but not a deal-killer.
Of course, if command line commands can be used reliably when the GUI is open (the DB supports access by multiple processes), then one could build real batch files. This sort of scheme wouldn't be as convenient, however, because the command line functions 'set' things instead of 'editing' them.