I am highly skeptical that consistent frame rates will be possible with this architecture; IIRC byuu considered and rejected such an architecture for bsnes for performance reasons. Granted hardware has advanced since then, but single-threaded performance hasn't advanced a whole lot in that time, and that's what you're going to run into a bottleneck with this.
There were two reasons I rejected the idea. Foremost was that my goal was code simplicity. Although true that most of the time you can run ahead without issues, it is no small feat to be able to serialize tiny deltas that can then be rewound when a synchronization error is detected (a full system state would be far too costly to capture and rewind.) Further that with all of the pain that traditionally comes with multi-threaded programming (especially in portable C++), and I found cooperative threading to be far cleaner and easier to debug, and thus, to refine accuracy on.
The second reason is that my approach ended up needing about 2GHz to run well for the SNES. Nemesis' approach needs about the same, but also needs a quad core to run well with the Genesis. Since I was able to pull off all I needed with a single core, why require a quad core system? Any quad core will have a fast enough individual core, after all.
That said, it's actually my approach that won't scale well, as mine is bound to one core whereas Nemesis' approach is not. It's part of the reason I haven't attempted the N64 or higher. If you ever want to see more accurate Saturn emulation or similar, Nemesis' approach is going to be the way to go.
As an aside, we've been hearing about the 'end of the free lunch' for a decade now. All I can say is my slightly overclocked i7-2600K runs my emulator nearly twice as fast as my previous E6600. And I hear the Haswell will be 15% faster per clock than the Ivy Bridge, which was 10% faster per clock than the Sandy Bridge. That and it's clocked higher. I don't foresee us running out of optimization potential any time soon, and by then who knows ... we may be able to create graphene processors or something even more exotic. Necessity breeds innovation.
The bigger concern on 'free lunch' is the push toward mobile devices and lower power usage (longer battery lives.) But for that I think you will always want a speed-oriented emulator, so programs like Snes9X and Gens are more appropriate there anyway.
It should be possible, providing you can keep enough information to handle potential rollbacks (you should be able to limit yourself using regular sync points which would make that job easier), especially if you keep profiling information to keep track of areas of code that do require synchronisation.
Main thing you need to ensure is that all the modules accurately track internal time so that synchronisation events do work accurately.
