But then there’s something I don’t understand: at which point in the code are those new data names extracted to the translation files?

In BKE_modifier.h there is this declaration:

typedef struct ModifierTypeInfo {
  /* The user visible name for this modifier */
  char name[32];

And in modifier.c:

static ModifierData *modifier_allocate_and_init(int type)
{
  const ModifierTypeInfo *mti = BKE_modifier_get_info(type);
  ModifierData *md = MEM_callocN(mti->structSize, mti->structName);

  /* NOTE: this name must be made unique later. */
  BLI_strncpy(md->name, DATA_(mti->name), sizeof(md->name));

Does it not mean that new modifiers get their names from this name property in ModifierTypeInfo? If so, they actually are exposed to the user. And their translation does happen, but the strings never get extracted to the po(t) file (I think).

Anyway, I couldn’t find how to handle the string extraction better than using the macro where they are declared :)

Fair enough, I’m not skilled enough to investigate further!

Understood, I just thought it looked inconsistent when tooltip translation is disabled, since they’re not popup (which I thought all tooltips were):

Aaaaah right, they are used there as 'data' name...

Thought those were extracted automatically by the script from the RNA data, but those default names are not exposed to RNA in the end...

So you are right, we need those tags here.

In fact, we also consider lengthier, informative 'labels' as tooltips from translation perspective.
the idea is that, user can choose to only translate tooltips, but not labels, so that they get a UI that matches most (English) tutorials and docs, while still getting detailed info/explanation in their native language (the tooltips).
In that sense, it makes more sense to keep detailed 'labels' such as error messages or info in the 'tooltip' category.

Those three should also be tagged then?

Well there are many untagged subpanels left, probably around 60. I only did those which weren’t already in the po files from somewhere else in the code.

Should I add all of those for completeness’ sake, if the other sources are ever deleted?

in fact decided to add those function (this one, and also the one for gpencil modifiers) to the automated messages extraction script , simpler and more future-proof. So you should now be able to remove manual tagging for them.