It doesn't duplicate so much as do it every single time. For Source, you can go into the menu and change the frame rate of the game, or set frame rate to 0, and set a button to frame skip by 1. (essentially, frame advance and slowdown.) However, the game is in a strange kind of state during these 2 modes of play (since you can't precisely pause/unpause, or change the framerate during gameplay.) When the framerate is changed, the games freeze when trying to load any maps (which is what happens when you use load, it tries to load the map the same way as if you were starting the level, just from the point where you made the quicksave.)
Now it gets trickier in that, if I remember correctly (demonstrate, correct me if I make a mistake) but there's randomness that occurs during loading of saves. For our current emulators, there's frame count, and when you make a savestate, loading the savestate will bring you to the exact frame that you saved from, with the game being entirely the same. In Portal, there were two inaccuracies. One, sometimes objects (in what we tested, an energy ball) that if we loaded successfully and told the game to pause as soon as a load was saved, it'd randomly be in slightly different positions. Secondly, in order to work around the game crashing, we tried creating a script where while the game was in timescale or framestep, to deactivate it, load the save, and reactivate frame step as soon as the load was complete. Now the problem is that a random number of frames would pass by before the game was loaded. If we told the script "when pressing X button, deactivate framestep, load save Y, wait 5 frames, activate framestep" then the game would occasionally crash. Sometimes the load would work without crashing, but we wouldn't be on the exact frame that the save was made, and sometimes frame step was activated too many frames early and the game would crash. We couldn't identify the source of the random frames, so we had essentially savestates that would either cause the game to crash or would load us on the wrong frame count.
There's two other problems I encountered, with Portal specifically. One, the game runs at 300 frames per second. (Was it 300? I forget, but something really high like that.) Portal's camera works like this: where your mouse is pointing, you turn and look. This would, using frame advance only, create the most spastic camera work ever, with 300 crazy camera movements per second. Because during framestep you can't hold down the button, you can't create smooth movement, and the end movie would most likely cause anyone to throw up from motion sickness.
Like this.
The other problem with such a massively high framerate is that since you can't hold down the frame advance button, you have to press the frame advance button 300 times in order to progress just one second. And the frames don't load very fast in framestep. So it'd be a very, very slow process.
One other thing I forgot to mention. When we worked with Portal, we used Source's own built-in movie record features, which essentially works exactly the same as input files, in that you can send the movie file to someone else's computer and have the game play through inside the game itself, just like our emulators do.
