No offence to the OP but this has been discussed to death in this forum already.

It's worth reiterating that if you're using nVidia then you have a perfectly good frame rate limiter available to you via Inspector (as long as your drivers are up to date). I use this one, as well as triple buffering via D3DO.

Some details on the subject:

1. The basic flaw appears to arise from using GetTickCount for game logic timing. GetTickCount normally returns a number of milliseconds that increases by 15 to 16 milliseconds every time that 15.625 milliseconds of real time pass. In theory that should produce a subtle 4 Hertz beat frequency on games like Oblivion when FPS is maxed out on and the monitor is running at a 60 Hertz refresh rate, where the game does 14 frames in which 15-16 millieconds of game time pass per frame, then one frame where 31-32 milliseconds of game time occurs, then repeat. The relevant code for that in Oblivion is fairly simple and does not appear ambiguous, though other methods of timing are used for some other purposes (IIRC QueryPerformanceCounter is used for performance monitoring and on some sound cards something else is used for lip synching, but not on other soundcards) and it is concievable that something less obvious is effecting things somehow.
Note that a wide variety of software uses GetTickCount in basically this way.

2. GetTickCount is, I've heard, implemented in the hardware abstraction layer, with the most common implementation (described above) being the reference implementation provided by Microsoft. It may vary slightly on some exotic computers, possibly including Xboxes. The behavior I described in #1 above is what I measured on my own computer and confirmed on every other computer I've tested GetTickCount on.

3. A few people do report something that looks like what theory would predict on Oblivion. Most people report not noticing such a thing on Oblivion, or noticing it but it being very minor. I personally have never noticed anything like that from playing Oblivion. When GetTickCount calls are patched to use finer resolution timing instead those people report the issue to be fixed. Oblivion Stutter Remover is the standard fix (it also does a bunch of other stuff).
Note that Oblivion had plenty of other unrelated issues that cause much worse stutter, but the 64 Hertz issue is the only issue that occurs all the time no matter what is happening in the game (unless the game is paused).

4. The FO3 & FNV game logic timing code is slightly different. I have not investigated exactly how it is different, since the issues related to it are readily fixed by the same GetTickCount hook as Oblivion. On FO3/FNV, a very large number of people report (and sometimes show videos of) severe issues on Fallout 3 and Fallout New Vegas that look vaguely similar to what a 4 Hertz beat frequency should look like, but are probably too much worse than the Oblivion issue to be really the same thing. When GetTickCount calls are patched to use finer resolution timing instead those people report the issue to be fixed. I personally do not notice the issue they describe or show in videos on my FO3 install, but I *do* notice an equally severe issue with NPC animations that goes away when GetTickCount calls get patched (why do I never hear anyone else talking about the vibrating NPC animations?). Fallout Stutter Remover fixes these issues on FO3. New Vegas Stutter Remover fixes them on FNV, and so does the 4GB enabler linked from the NV script extender web page.
My presumption is that FO3 / FNV added some sort of issue with scheduling, inter-thread communication, or multiple time measurements per frame that amplified the effect of the 64 Hertz issue. But I don't know, I've never looked for code relating to the issue.

-----
Anyway, if Bethesda coders happen to read this, please avoid using GetTickCount on the PC, and think carefully about any timing done for game logic or animation purposes.

Will we ever get a fix for this?

I tried the frame rate limited in MSI afterburner, but it made load times instantly go up from ~15 seconds to nearly 1 minute. Then again, I had the frame rate limited to 30 FPS in an attempt to reduce VRAM usage in certain areas. It worked great to reduce VRAM usage... for a while. But the inevitable would eventually happen regardless.

I tried the frame rate limited in MSI afterburner, but it made load times instantly go up from ~15 seconds to nearly 1 minute. Then again, I had the frame rate limited to 30 FPS in an attempt to reduce VRAM usage in certain areas. It worked great to reduce VRAM usage... for a while. But the inevitable would eventually happen regardless.