Request: Improve addressability of embedded pictures

What I would like to see:
The functions of the picture context menu should all be reflected in actions and reports.
Some already are but what I miss in particular:
Set the %_cover_type% of an existing cover with an action.
Background: I see a lot of podcast that - for some inexplicable reason - have covers set to "other".
Right now the only way to set this to "front" (or whatever) is via the GUI but not as part of (cleaning up) actions.
The current workaround: export the picture to the filesystem, import it with the correct cover type set. Works, but has the drawback that I am left with a picture file in the filesystem which has to be deleted with functions outside MP3tag.

Modify the picture description with actions / modify it in the context menu for several files in one go
At the moment, it is neither possible to modify the picture description with an action nor is it possible to modify the picture description for more than one file at a time via the GUI.

The current workaround: export the picture to the filesystem, import it with the correct cover type set. Works, but has the drawback that I am left with a picture file in the filesystem which has to be deleted with functions outside MP3tag.

Filter for files with a picture description
This function is currently not available.

Delete a specified cover type from the file
At the moment, it is only possible to delete all embedded pictures regardless of their type. I would like to see a function that allows me to delete only one particular cover type.

The current workaround: export the picture to the filesystem, import it with the correct cover type set. Works, but has the drawback that I am left with picture files in the filesystem which have to be deleted with functions outside MP3tag.

Address the properties of the individual embedded covers in reports
Currently it is not possible to access the properties of any other embedded cover than the first, most likely the front cover. Even though %_covers% accurately reports the number of embedded covers, it is not possible to perform a $loop() on the variable %_cover_type% - or to be accurate: the loop stops after the first cover and ignores the other covers.
For this, I see no workaround.

Yes, I would like to have it too.

In the meantime ... have a look into some old forum messages ...
https://www.google.de/search?q=site%3Amp3ta...+incoming+files

Once jpg files are in the view of the Mp3tag filelist, then they can be treated by Mp3tag, ...
regarding their file path name.

DD.20170810.1044.CEST

Thank you for the reminder.
Yet, it is not quite the same:
Regardless of the fact that the jpg-files clogg the view with more or less empty entries, it is also not really a convenient way as MP3tag does not add the files to the displayed files although MP3tag is the source for the alterations in the quantities of files.

This means that you have to reload the current selection - and this could take time, depending on the number of files that were treated before.

So the detour via the file system is a workaround to sail around the gaps (can you do that? Sail around gaps?!) in the user interface.

It would be much more elegant if information in ID3 tags could be treated in MP3tag.