The caching mechanism does not take into account the modification of a file which keeps its name (so as not to lose its insertion in multiple playlists) but is intrinsically different (better recording quality, or more danceable version)
If the replaced version is longer (is the end-of-track silence marker counted from the end?) the end-of-track marker is retained during playback and therefore the piece is cut off before the end, which is catastrophic for the dancers' experience.
The cache should check not only for the presence of the file but also compare sizes and dates to validate the relevance of the information used.
Very easy to reproduce: replace a file with a shorter one, use the auto DJ with the mute option to switch from one track to another and on replay the broadcast will be truncated.
Additional note: deleting the end marker does not solve the problem, the track is nevertheless interrupted at the same marker which is however no longer visible.
Re-scanning the tracks before playback should solve the problem, but the behaviour is certainly not intuitively understood by users.
Re-scanning the library won't do the job. You need to reset all the information (ot at least the waveform, I suppose) related to that file. In any case, if you change the file also the key, BPM and replay gain might be different, so I think it's safer to reset everything.
Anyway, I agree with you it would be nice that Mixxx detected the new file and reset everything which is stored in the database.