Overhead Necessary For A More Flexible Timeline View

[Darius1968]

As it now stands, the said file(s) appear in the IMatch timeline, at one specific node, depending on the {File.DateTime} variable, which favors AFAIK the Date Subject Created. 

So, really, the file is gonna reside in the timeline, according to what a digital camera/smartphone/scanner sets as the original date.  This is probably the most desirable and optimum behavior. 

However, I've found, on occasion, that a friend (or whoever) has emailed me (or made available to me by whatever means) a set of digital photos from whatever event.  Although, I like to remember WHEN, with regard to the time these photos were actually made, sometimes, I find that I better remember a date, according to when the friend actually gave me the photos. 

With this in mind, would it be possible to enhance the IMatch Timeline View, such that the default reliance is upon {File.DateTime}.  But, also allow for the file(s) to reside in another place in the timeline (just like files can be assigned to multiple categories), according to the user setting one-or-more metadata tags to a 'database on setting', that would, in turn, instruct IMatch to also let said files also have residences at other nodes, corresponding to the 'on-position' of these other metadata tags. 

If this possibility were implemented, then the user wouldn't have to create other 'Micky Mouse' data-driven categories to, for instance, enumerate the Microsoft Date Acquired Tag ({File.MD.Microsoft::XMP\DateAcquired\DateAcquired\0})

[Mario]

As it now stands, the said file(s) appear in the IMatch timeline, at one specific node, depending on the {File.DateTime} variable, which favors AFAIK the Date Subject Created. 

Please see How IMatch uses Date and Time Information to learn why and which metadata timestamps IMatch uses for different file types.

So, really, the file is gonna reside in the timeline, according to what a digital camera/smartphone/scanner sets as the original date.

Not necessarily. That's the reason why IMatch (and other popular applications) favor the date subject created. Because:

a) This is either the same as the create data (set by the camera or smart phone)
b) it differs, because the image create time is not the same time the photo was created (e.g., digital scan of old photo or artwork)
c) it has been set by the user to anchor the file on a specific point in time

That's why there are two dates. They are usually identical in normal photographic workflows, but not always.

By (optionally) changing the date subject created the user controls where in the IMatch time axis the file appears.
This also applies to features like sorting, searching, time display, variables, the Timeline View and Event View.

With this in mind, would it be possible to enhance the IMatch Timeline View, such that the default reliance is upon {File.DateTime} (...)

Changing the timeline (and the Event View) to support different timestamps per file would complicate things.
Except for the standardized XMP date subject created and create date IMatch (and ExifTool) maintain, all other timestamps may exist or not, may be partially filled, wrongly formatted etc. Dealing with that can get ugly and I really don't want to go that route. Also, I think that the same file showing in different sections of the timeline could be confusing and probably even cause problems.
A file can be created only once, after all.

If you consider the proprietary Microsoft timestamp you mention as more correct, you can use a Metadata Template or the TimeWiz to copy this timestamp into the XMPdate subject created to anchor your file in the timeline and the Event View at that date.

If you want to organize your files by that timestamp (or any timestamp or metadata tag), a data-driven category works best for that purpose.