It's tricky/ impractical to fix the fsync() behaviour in data=ordered ext3.
My understanding of the problem is that it looks something like:
You, the application programmer delete file A, and create files B, C and D. You are writing to file B and call fsync(). I, the filesystem driver must now ensure that the data & metadata for B are on disk (survive a reboot etc.) before returning from fsync() or you will be very unhappy.
So I must flush B's data blocks. To do that I must allocate for them, and it so happens I use some blocks free'd by deleting A. So now I need to commit A's metadata update (deleting it) or else things may go tits up. Unfortunately that involves touching a directory, which mentions C and D. So now I need to commit C and D's metadata. And if I do that without pushing C and D's data to disk I am disobeying the data=ordered setting. So I will push C and D to disk.
Figuring out that I need to do all this is expensive, whereas just shrugging and pushing everything to disk is cheap, yet even if I do all the hard figuring I may still have to push everything to disk and now I've also wasted a lot of CPU figuring it out. So you will understand that nobody is anxious to take on the thankless (see the feedback to Tytso from Ubuntu users) yet very difficult task of trying to do better.