The ./ltximg directory (or more precisely the value of org-preview-latex-image-directory) is searched: not only is it searched first, it is the only place where Org mode looks for images.
The problem is the filename it is looking for: it is of the form org-ltximg_<hash>.<imgtype>. The image type is png by default and, although it can be changed, I suspect that all of your images are of that type (if not, that explains the regeneration).
More problematic however is the calculated <hash> value, which depends on a number of things:
...
(hash (sha1 (prin1-to-string
(list org-format-latex-header
org-latex-default-packages-alist
org-latex-packages-alist
org-format-latex-options
forbuffer value fg bg))))
...
If any of the things that it depends on happen to have changed, then the calculated hash value will be different and the file will be regenerated. Some of these things are easy to check: the various options listed may have changed default value between the two versions, or you might have customized one or more differently between the two versions.
The four things on the last line: forbuffer, value, fg and bg, are more dynamic and therefore more difficult to check.
forbuffer is an optional parameter to org-format-latex (where all this cookery is done) and its value is a constant and unlikely to be different in the two versions (for the record it should be the symbol forbuffer). Both ox-html and ox-odt call org-format-latex with the forbuffer parameter set to nil, but if you are generating previews manually, that is unlikely to cause the hash to be different.
value is calculated as the :value property of the context of the image element in the Org mode file, so if you have not changed the Org mode file, it is unlikely to have changed (but maybe there was a change in the org-element parser that produces a different value - this is more difficult to check and I have not gone deeply into it).
fg and bg are the foreground and background colors of the generated image and may have changed.
All of these calculations are done in thirty lines of code, starting on line 15769 of org.el in my version of org.el (very recent update from upstream).
The upshot is that it will not be trivial to figure out what has changed, but you are the only one who can do that, since you have the filenames with the (previous) hash already on hand. If you can go back to your previous version on another system while using your current system for comparison, then you could use a debugger (e.g. edebug) to put a breakpoint after the hash calculation and then compare the values of the various variables that you get in the two versions. That's tedious and fiddly and will require some patience: I'm not sure it's worth it, but you are the only one who can decide that. Otherwise, I'm afraid you'll have to live with regenerating the images, plus the possibility that the same thing will happen after the next Emacs update.
