Comments:
2. The cycling is broken if you have one file without an extension with a given name and another file with the same name and an extension. For example, all 5 of my projects are currently Ruby on Rails repos. Every RoR project has a `Gemfile` and a `Gemfile.lock`. When I try to find a particular Gemfile, C-Tab gets stuck on the first one. This has always been the case with C-Tab, so it doesn't bother me, though if there is a workaround I'd love to know it.
3. Yes, I see the message "[File Cache: complete but not unique]" whenever it gets stuck. This has always been the case for 2, above, and in Emacs 27.x (and presumably 28.x) it is the case when a duplicated file has a duplicate and also another file with a similar ending. In my case, there are 9 files named `dashboard.rb` across several projects, and even more files across several projects that follow the pattern `*_dashboard.rb`.
4. The cursor-jumping-to-the-beginning-of-the-filename behavior is new in Emacs 27.x. It doesn't happen in case 2, above ... though that's because the overlap termination location in that case is at the end of the completed file name (the dot in `Gemfile.lock`). Whereas in the new behavior, the overlap termination location is at the beginning (e.g. in my project, the underscore in `db_dashboard.rb` or `homepage_dashboard.rb`).
In any case, the larger issue is that a prefix overlap is now causing C-Tab to get stuck. The point goes where it should to assist the User in resolving the overlap. It's not where the point goes but rather that Emacs gets stuck on the common suffix that is the new issue.