It’s nice to see the enthusiasm (both pro and con) on this issue. I just want to clarify that it has nothing to do with a class room setting, where the changes file is being shared or copied so students have access. I have run into the corrupted .changes file problem myself a couple of times for two reasons mainly:

a) I’ve done a lot of work but need to check something against code that wasn’t modified (and no, checking package changes in Monticello wouldn’t help in the case I’m thinking of. Imagine for example a huge refactoring across multiple packages). So I open a second copy of the image. I keep both images open because its convenient but at some point I accidentally make a change in the wrong image. Now I’m screwed.
b) I forgot that I already had the image running (e.g. minimised). I start a fresh copy and work on it until I realise that some of my method sources are broken. Again: screwed.

Another thing I want to mention is that the semantics of flush depend on the operating / file system (I have experienced this first hand between Linux (ext4) and OS X (HSF+)). Just because you’ve flushed you’re buffer doesn’t mean that the contents have actually been written to the file. So while it may be true that there is a #flush missing somewhere I would not expect that adding the #flush will solve the problem entirely (which is one reason for proposing a locking mechanism in the first place).

Cheers,
Max