It appears detection of files being modified on disk is subtly broken. The impact on the user is often not so subtle. The issue I experience most often is that switching branches, where some files exist only on one of the branches), does not reload files properly.

I tried to fix this in my 2018 snapshot of kate (I'm still using that because I don't like the newer modified files UI). It turns out there are many issues, some of which definitely still exist in git master. For example take this line:
https://github.com/KDE/ktexteditor/blob/master/src/document/katedocument.cpp#L5007
The createDigest() call is updating m_buffer's digest - even if the file is not going to be reloaded! Likewise, and this is the problem I'm mostly observing, if a file is created/deleted it will check against a possibly outdated digest. I think the main problem is that the invariant, that m_buffer's digest shall match with the buffer contents, is not properly observed. Actually, you can wonder why it maintains a digest at all, instead of just comparing the buffer contents.

When I tried to fix this, I couldn't get it right, but maybe I got confused by all these buffer types and code paths. I ended up disabling the "clever" reload behavior, and just prompt the user with any changes that might have happened.

There's also the heuristic to simply reload files if they match a git object (i.e. without asking the user, even if auto-reloading is disabled). While in principle useful, I think it's not valid. Just because a certain version of a file existed once in the git repo, it doesn't mean it'll be easy for the user to restore the old version. The blob could even be dangling, to be garbage-collected at git's next opportunity, instead of being connected to a branch. If this is actually the case (I don't claim to understand the code very well), this is Bad. If anything, it should check whether the change was directly related to a certain "git checkout" command (or similar). That means, auto-reloading would be OK only if the old version was in the previous git HEAD, and the new version is in the current git HEAD.

And even then, it'd be nice if it didn't auto-reload, but instead the affected files would show a special status in the reload dialog.

How to reproduce? This is pretty simple. I'll list two cases which are particularly "common":
A)
- have a branch that adds a large file (maybe at least 40KB on a SSD)
- make sure it's part of the project settings, maybe open the file
- git checkout a branch that doesn't have the file
- click on the file (kate might show a "New File" notification)
- click on another file
- git checkout the first branch again
- the file is not reloaded properly
B)
- delete a file that was opened
- possibly click on another file, then the first file again
- create the file and/or append some text to the file on the shell
- it won't be reloaded properly (sometimes only on the 2nd change)