Not really. Git tracks content and not files. File renames doesn't exists in git. When git tell you that a file is renamed it's because an algorithm guesses that a file is renamed (if the content is similar).
Exactly, so any rename should be done without other edits in the same commit, so the content hashes exactly the same. Any bulk rename in a repo would satisfy that and be a non-issue.
Of course, this is impossible in languages where file names and namespaces / structures must align. But nobody uses those, right?
Even in those you would rather rename first then fix it in a subsequent commit, and just accept that the intermediate state isn’t correct.
Why is having an obviously-incompilable intermediate state in your history a good idea, rather than using a diff algorithm that will find the move anyway?
Not sure I follow. So long as git understands the move so a single file history (using the standard command or standard IDE tooling) doesn’t “stop” before the rename, then I’m happy. And I’m very happy to accept one commit in the history that doesn’t build in order to get that.