If a new texture is used for each mesh, I don’t see any way to track a given point on the original mesh.
The only option left is to somehow get attached to a “geometrically-special” point (like a “button”) or a “color-special” point (“bright spot”), and try to track it out.
Sorry for late reply…internet was out .
Each character has a single ‘texture’ imported that is an .ifl file…so a series of textures.
In the case I’m working on, the character animation length is 180 frames, and the mesh changes 28 times in that duration. Everytime the mesh changes poly or vertex count, so does the overall layout of the texture map. During the times the poly count doesn’t change, the layout of the tex map doesn’t change, but you can see the individual sections of it updating (facial expressions, movement of cloth wrinkles, etc.). So every image in the ifl file is different.
If you’d post examples of what you’re working with, we could try to work something out and help somehow.
So, think of ways to get around the NDA. 
How fast is the object moving between mesh changes? If it’s not moving that fast, why not compute a predicted location based on velocity, and then do a search for the nearest vertex?
does that work ? you need to know 2 positions to compute a velocity but you only have one, you can take the velocity from the average of all the verts but if just the arms waving about and the legs are not moving then you’ll be looking for verts in places they aint.
think you need to somehow break each mesh in to clusters loosely based around a typical human rig and weighting and go from there… it’s some pretty serious coding required and way beyond a novice.
another approach could be just sort the verts — create a best fit transform of each frame like a root node in a trad rig… transform the verts into that coordsys then sort in z, then x and finally y ?
but still that would be useless for say a roundhouse kick or just a walk cycle back leg front leg back leg front leg 
According to OP, the example mesh changes 28 times in 180 frames. So, average of 6 frames where the mesh doesn’t change, should be enough to compute a reasonable velocity.
There would still be some margin of error from the velocity calc. and nearest vertex on the subsequent mesh. At the very least, it may be good enough to at least aid whomever is doing a manual process or fine tuning.
Right now, the best I can do because of the NDA is create an example that sets up what I’m trying to do…
I’m reaching out to the client about what I can show and can’t show, but won’t know for a week or so.
I like the idea of trying to figure out the velocity…is that possible via a vertex level? I think we ould also need to figure out the new angle being traveled.
Here’s a test Max file I created, along with my starting maxscript, and an image file to explain.
I’m a novice a this stuff, and in the scripting, so I have no idea how to get the velocity or angle, if it’s even possible at a vertex level.
Thanks!
Predict Next Vertex.zip (182.3 KB)
