I guess the question is because this would be the only field (in addition to the publishedIn field) that has a transformation step in the fallback template.

Note that even though this transformation step is included in the fallbackTemplate.ts file used by w2c-core, it is not included in the templates.schema.json file used by the JSON editor.

This templates.schema.json file does not include the default range transformation step in the publishedIn field, probably assuming that, because publicationTitle, code and reporter all map to the same base field, it's impossible that more than one is included in the Citoid response.

Hence, consider removing this transformation step from the fallbackTemplate.ts file as well, and renaming this task accordingly.

Citoid output will be valid YYYY(-MM(-DD)) date already.

This is not true. Although Citoid Exporter.js' function fixDate says that it will delete a date if it cannot be converted to ISO, truth is that if an error is found during parsing, the date is kept unmodified.

As a result, Citoid may actually return any string in the date fields. See for example this URL (archived here), for which Citoid is returning "1900-1909". Actually, I tested the code locally, inserting a breakpoint and changing a date field value before the fixDate function is called, and had Citoid return whatever string I wanted.

Hence, the date transformation in the fallback date field may reduce the cases where a date field would be missing, but may result in wrong force converted dates. For example, the "1900-1909" date above is incorrectly converted to "1900-09-10" by the date transformation.

may reduce the cases where a date field would be missing, but may result in wrong force converted dates.

This case of Citoid returning a value not valid in Web2Cit is related to T313236.