Lately I've been playing around with MusicBrainz WS scripting, and I've come across the following roadblock:
Defining a cover size for preview thumbnails can be done in the script; however doing the same for cover size in results is more difficult. This is because Mp3Tag already has cover options built-in (in File>Options>Tag Sources>"MusicBrainz Cover Size"); and those take precedence from anything written in a script.
Since the introduction of the Settings schema, its now possible to create a Settings menu that enables setting cover size for results; but -in the case of MusicBrainz specifically- for those settings to be applied, an extra step of going to Mp3Tag's program options and setting the cover size to "default" is mandatory, and only then can WS script settings take effect.
My suggestion is to rework -or even remove, if possible- MusicBrainz's fields from Mp3Tag's settings, since they can be written from within a WS script.
This is merely a suggestion, but in my opinion I think this would be a change for the better, since it would give (MusicBrainz) web source script authors more possibilities (and lighten Mp3Tag's code).
The other way around would be a command in WSS that disables existing settings.
Something like UseMusicBrainz_CoverSizeSettings "off"
the default setting would be UseMusicBrainz_CoverSizeSettings "on"
Such a setting would not render existing WSS inoperable.
MusicBrainz (the CoverArtArchive.org to be more specific) offers 4 cover art sizes:
If someone needs another cover art size like 625x625 pixel I would suggest to use an Action "Adjust Cover" to reduce a bigger cover art to the exactly needed size.
Such an Action has the additional advantage that it doesn't mind what the source of the cover was. It adjust all covers in the selected files to the given Max. size.
IMO, since the settings schema is meant to give the possibility of having variable options for WS scripting with a user-friendly interface, having those hard-coded in Mp3Tag's settings feels redundant. And if sometime in the future CoverArtArchive.org changes their offering of cover sizes, there would be no need for a new version of Mp3Tag to maintain compatibility.
But for legacy support of existing WSS, your suggestion is the best one. My suggestion was not one for the immediate, but to be considered down the road.
