I don't follow. Where did you read that?
The Imatch help says:
In order to match your track log with your files, IMatch compares the GPX timestamps with the 'created' time stamps in your files (EXIF datetime created, if this does not exist, EXIF datetime digitized).
which also agrees with what I see IMatch does. Although I assume IMatch works with the database values rather than EXIF fields directly - for example, the track log function considers time zone data in the "Create Date" which is not present in embedded Exif if I understand correctly.
It's maybe 2 or 3 years that I worked on that, it's functioning ever since. No problem reports or change requests, ever.
The date subject created usually only differs from the create date when you digitize old images (scanner....) or when you later manually enter a subject create date.
When you take images with a digital camera, these timestamps are always identical.
My case is an edge case that doesn't occur often since 99% of all uses of the tool probably deal with images straight from the camera.
I have a set of images given to me by another person, where images have been edited such that there is a new "Create Date" in the Exif data. I can see that this may be an incorrect use of metadata, but it also seems logical that if an image is exported, the "Create date" would change and the "Date Subject Created" would remain the same. But perhaps not the embedded EXIF fields, only XMP or ITPC?
The other reason I ran into issues was that some files given to me have been stripped of Date fields for some reason. For those fields I have manually set "Date Subject Created" and left the "Create Date" as is (taken from the file system meta data). This is according to the logic described in the Help:
The Date Subject Created is the more important timestamp and when you set or change it, IMatch updates File.DateTime from the new value automatically.
It would make sense to me that the track log tool uses the same date information as the file viewer does when sorting according to Capture Time.
Both cases can be solved with the existing track log functionality by simply copying the "Date Subject created" to the "Create Date" field. However, I argue that track log functionality should always prefer "Date Subject Created" to also cover for the small fraction of cases when these two fields differ. Now it is the other way around.
It is also entirely possibly that I have misunderstood the meaning of the two fields, but I have tried to follow the documentation. Again, this is an edge case and I understand that you hesitate to change what is working for most. I can work with the current implementation but it would be better for me, and I think correct to do it the way I propose.