This "elementary stuff" is mostly already implemented :-) Including the version and checksum verification and file rollback. But the whole game is not rolled back, because in most cases the differences that cause the errors are small and don't really break the patching process.

Basically we provide patches for our versions of games, assuming they were more or less unmodified since the installation. We can't predict or handle any modifications someone can make to the game.

If you get the error log, then you know what changes weren't made, so you know how to proceed. Other changes are still done normally - the patcher doesn't just stop and exit. If the errors are minor (readme file wasn't changed), you can proceed and play the game. If not, or you don't know, you can always reinstall the game and try again - and the patch will work with a fresh install.

Patcher proceeds with the process even if there are some differences, because in most cases they are minor (like changed settings file) and it works. If the game is heavily modified, there is no good way to handle that, aside from not doing anything. And there is no way for the patcher to tell if the changes will be minor or critical.

I see your point, but what you described (multiple patching with manual file swapping) is not really what the patcher was optimized for. But thanks for the input, there's always room for improvement :-)