That will then require to load and write the property map twice when properties only specific to some tagging formats need to be written, see e.g. Ape and Vorbis tags in D18604. I would like to avoid this.

So iff the rating is updated at the same time as another property, taglib has to adjust some in-memory structure twice. Obviously, for most formats this poses no problem, but for Ape/Vorbis it does?

Also, this no longer applies when you use the specific tag types for Ape/Ogg.

Writing to disk only happens when calling file->save()...

Not sure I understand. I would like to avoid doing file->properties(); and file->setProperties(); twice for those formats for which only the PropertyMap is sufficient, e.g. Ape and Ogg, to avoid doing any unnecessary work. The beauty of Ape and Ogg in the TagLib implementation is that they solely work with the PropertyMap and do not require any special handling. See D18826, Ape and Ogg do not have any extra codepath at all. For writing tags, we have to be a little bit more careful, though. If writing Rating information is added to writeGenericProperties, for example Id3v2's "TXXX" tags will be polluted with these values.

I think for reading it as generic as possible is fine, but for writing being a little bit more explicit does not hurt.

My proposal for Ape and Ogg is to split the writing for these to two different functions. Yes, it is possible to use the propertymap for both, as both use the same scale and the same tag name, but the implementations on the taglib side are completely different.

Writing the "rating" for XiphComment (Ogg) and Ape in distinct functions (see my comment in D18604) hardly adds any code, but gets the Ape and Ogg code paths in line with the other file formats. You don't write the ASF/MP4 rating using the property interface although it would be possible, and IMHO thats the right thing to do, also for Ape and Ogg.

As soon Ape and Ogg are split, you no longer rely on the PropertyMap for the rating, and you won't have to use properties()/setProperties() twice.

No, I cannot use the the PropertyMap for ASF/MP4, those atoms/attributes are unsupported in the PropertyMap and need to be handled separately. I would have done so if it is possible.
I really do not like to write unnecessary, duplicated code when TagLib handles this nicely for us. I've only chosen the rating property to be implemented first, but there are more to come. The code will be 100% the same for APE and OGG with the PropertyMap, and also more efficient as we query the PropertyMap anyway.

Taglib does not "handle this nicely". For APE and Xiph, it just accepts *any* unknown key and uses it verbatim, while for MP4 and ASF it rejects any unknown key.

The setProperties() is also quite inconsistent, for APE and ASF it only removes items which have an empty value, while for Xiph, the properties are completely replaced.

As soon as you add support for a property where APE and Xiph key naming differs, or is only supported by one, you will require two functions anyway.

Using APE::Tag::setItem(...) is as efficient as manipulating the key/value in the Taglib::PropertyMap first and setting it by setProperties(...). Likewise for Xiph.

If you want to squeeze out the last bit of efficiency, you would skip the setProperties(...) completely when no property is changed by writeGenericProperties(....). This happens e.g. if you only change the rating.

If you want to avoid duplicate code, move the properties()/setProperties() into writeGenericProperties(), that saves 12*2 lines and adds 2.

Taglib does not "handle this nicely". For APE and Xiph, it just accepts *any* unknown key and uses it verbatim, while for MP4 and ASF it rejects any unknown key.

And so do APE::Tag::setItem and OGG::XiphComment::addField ...? btw, also perfectly legal, APE and Xiph allow writing arbitrary tags, while the others do not.

The setProperties() is also quite inconsistent, for APE and ASF it only removes items which have an empty value, while for Xiph, the properties are completely replaced.

Xiph explicitly allows multiple entries per key, which need to be removed when writing.

As soon as you add support for a property where APE and Xiph key naming differs, or is only supported by one, you will require two functions anyway.

TagLib automatically translates different keys from APE to "common names", e.g. DISC->DISCNUMBER etc.

I would really like to hand off manual tag handling to TagLib as much as possible. The library solely responsible for reading tags usually knows better how to handle the tags than we do (with a few exceptions to the rule of course).