I assume that if I'm writing to a file and lose power, the file will revert to what it was. This is the way it works in journaling file systems like ext3 and NTFS. In ext4, your file gets blanked out.
The "fix" they included in 2.6.30 only decreases the chance of losing your data. ext3 is still more reliable.
If that's the behavior you want then you're supposed to use fsync(). Some software didn't do that and relied upon the non-guaranteed behavior of the file system.
Note, that this isn't a problem specific to ext4, but one that affects any file system that uses delayed allocation, like XFS, which uses similar measures to provide the the wrongly assumed behavior.
In this case the problem arises because ext3 performs synchronization every 5 seconds, whereas ext4 performs it every 2 minutes, to queue up more writes and increase performance. So the window of data loss without using fsync on ext4 is on average 1 minute, whereas on ext3 it's 2.5 seconds. This behavior isn't guaranteed anywhere, instead if your write is critical then you should use fsync. From the fsync man page:
The fsync() function is intended to force a physical write of data from the buffer cache, and to assure that after a system crash or other failure that all data up to the time of the fsync() call is recorded on the disk.
The real solution is for authors to fix their broken code, one major example of this was Firefox using fsync to maintain the integrity of its sqlite databases.