Any machine that draws without a framebuffer (NES, C64, Atari 2600) would be pretty complex if you'd have to manually handle these timings.
However, in the NES example you could perhaps embed a NES emulator and hook into its drawing code instead. But that does mean that the emulator itself doesn't introduce any glitches or flaws of its own, of course. At least you'd be able to get some decent timing information from the emulator to properly handle sprite multiplexing and whatnot.
Minor correction, the C64 does frame buffering. Timing and accuracy is still a major concern for all these platforms, though (especially the 2600, where even horizontal sprite positioning is based on the relative speeds of the pixel clock and the CPU).
For a platform that doesn't quite viciously depend on perfect timing (or some of the simpler NES and C64 games), say like the MSX, the concept of sprites and tiles could instead be a very useful abstraction for this kind of remake. No need to deeply examine the code; just capture VRAM and video register writes.
Sorry, I should have been more accurate. I was indeed trying to refer to all the crazy raster-level tricks that people would do, to multiplex sprites, change palettes, etc
However, in the NES example you could perhaps embed a NES emulator and hook into its drawing code instead. But that does mean that the emulator itself doesn't introduce any glitches or flaws of its own, of course. At least you'd be able to get some decent timing information from the emulator to properly handle sprite multiplexing and whatnot.