My idea is to track a specific file on a file-system over time between two points in time, T1 and T2. The emphasis here lies on looking at a file as a unique entity on a file-system. One that can change in data and attributes but still maintain its unique identity.
The ultimate goal is to determine whether or not the data of a file has (unwillingly) changed between T1 and T2 by capturing and recording the data-hash and creation/modification attributes of the file at T1 and comparing them with the equivalents at T2. If all attributes are unchanged but the hash doesn't validate we can say that there is a problem. In all other cases we might be willing to say that a changed hash is the result of a modification and an unchanged hash and unchanged modification-attribute the result of no change on the file(data) at all.
Now, there are several ways to refer to a file and corresponding drawbacks:

The path to the file: However, if the file is moved to a different location this method fails.
A data-hash of the file-data: Would allow a file, or rather (a) pointer to the file-data on disk, to be found, even if the pointer has been moved to a different directory, but the data cannot change or this method fails as well.

My idea is to retrieve a fileId for that specific file at T1 to track the file at T2, even if it has changed its location so it doesn't need to be looked at as a new file.
I am aware of two methods pywin offers. win32file.GetFileInformationByHandle() and win32file.GetFileInformationByHandleEx(), but they obviously are restricted to specific file-systems, break cross-platform-compatibility and sway away from a universal approach to track the file.
My question is simple: Are there any other ideas/theories to track a file, ideally accross platforms/FSs?
Any brainstormed food for thought is welcome!
It's not really feasible in general, because the idea of file identity is an illusion (similar to the illusion of physical identity, but this isn't a philosophy forum).

You cannot track identity using file contents, because contents change.
You cannot track by any other properties attached to the file, because many file editors will save changes by deleting the old file and creating a new one.

Version control systems handle this in three ways:

(CVS) Don't track move operations.
(Subversion) Track move operations manually.
(Git) Use a heuristic to label operations as "move" operations based on changes to the contents of a file (e.g., if a new file differs from an existing file by less than 50%, then it's labeled as a copy).

Things like inode numbers are not stable and not to be trusted.  Here, you can see that editing a file with Vim will change the inode number, which we can examine with stat -f %i:

$ touch file.txt
$ stat -f %i file.txt
4828200
$ vim file.txt
...make changes to file.txt...
$ stat -f %i file.txt 
4828218
Tracking a file over time