EXIF_DATA_OPTION_FOLLOW_SPECIFICATION unset does not prevent non-standard IFD1 tags (0xA002/0xA003) from being dropped on load

[DevkanKafkas]

When loading EXIF data from a JPEG produced by a Motorola/Lenovo device (moto g 5G - 2023), tags 0xA002 (PixelXDimension) and 0xA003 (PixelYDimension) are present in both ExifIFD (correct location, describing the main image: 2304x1728) and IFD1 (non-standard duplicate, describing the thumbnail: 320x240).
After loading this data with libexif, the IFD1 copies of 0xA002/0xA003 are silently dropped, even though they exist in the raw file bytes (confirmed independently with ExifTool -g1). The ExifIFD copies are preserved correctly.
Expected behavior
I expected that calling exif_data_unset_option(data, EXIF_DATA_OPTION_FOLLOW_SPECIFICATION) before exif_data_load_data() would prevent this removal, since the documentation states:

"If the EXIF_DATA_OPTION_FOLLOW_SPECIFICATION option has been set on this ExifData, then the tags are automatically fixed after loading (by calling exif_data_fix)."

Actual behavior
The tags are still missing from IFD1 after loading, even with
EXIF_DATA_OPTION_FOLLOW_SPECIFICATION explicitly unset before loading:

ExifData* exif = exif_data_new();
exif_data_unset_option(exif, EXIF_DATA_OPTION_FOLLOW_SPECIFICATION);
exif_data_load_data(exif, (unsigned char*)bytePtr, arrLen);
// exif->ifd[EXIF_IFD_1] still has 5 entries, missing 0xA002/0xA003

This suggests the tags are either:

Filtered out during the raw parse step itself (exif_data_load_data_content or similar), independent of the FOLLOW_SPECIFICATION option, or
Dropped by some other validation path not controlled by that option.

Steps to reproduce
exifData Mobile.txt
exifData Windows.txt

cExifData* exif = exif_data_new_from_data(fileBytes, fileSize);
// or with the option explicitly unset, same result:
// ExifData* exif = exif_data_new();
// exif_data_unset_option(exif, EXIF_DATA_OPTION_FOLLOW_SPECIFICATION);
// exif_data_load_data(exif, fileBytes, fileSize);

Iterate exif->ifd[EXIF_IFD_1]->entries and check for tag 0xA002 / 0xA003.
Compare against exiftool -a -u -g1 -H output on the same file, which shows these tags present in IFD1.

Verification with ExifTool
---- IFD1 ----
0xa002 Exif Image Width : 320
0xa003 Exif Image Height : 240
0x0103 Compression : JPEG (old-style)
...
Environment

Additional notes
I understand 0xA002/0xA003 are only standard in ExifIFD per the EXIF spec, and this camera's placement of duplicates in IFD1 is itself non-standard. My question/report is specifically about the EXIF_DATA_OPTION_FOLLOW_SPECIFICATION documentation implying this option controls tag removal during load, when in practice unsetting it does not preserve these non-standard entries. Either the documentation should clarify that this filtering happens elsewhere and is not controlled by this option, or the option should behave as documented.
Happy to attach the raw JPEG and full ExifTool dump if useful for reproduction.