My two cents...
Maybe you could use words that describe the purpose of the methods instead of their functionality. For instance, if the whole purpose of the new fade methods is for using in system exclusive mode (and I don't even know if that's the case, btw), then maybe you can add words like "System" or "Exclusive" to the method names. Something like Game.SystemFadeOut().
Another option might be the Microsoft WIN32 way. Something like Game.FadeOutEx() for the new methods. The "Ex" functions in WIN32 are usually very similar to the ones without the "Ex" but they have more parameters, so the ones without the "Ex" are used for most common things while in cases when you need more specialized functionality, you call the "Ex" functions, fully aware that you'll be required to specify more parameters. Btw, AGS uses this scheme for playing sounds. It has PlaySound(sound_number) and PlaySoundEx(sound_number, channel).
Another option, a more object oriented one this time, could be to use a new object. If, for instance, the Game object, along with all it's attributes and internal parameters, encapsulates the things that are being saved to the saved games (it's just an example, I'm not saying that's really the case), then maybe a new object could be conceived, that encapsulates all other game attributes and parameters that are not saved to the saved games. In that case, you don't have to come up with another name for the fade methods because they will belong to different objects now. You'll have a System.FadeOut() method, for example, as opposed to the Game.FadeOut() method that exists today. I agree that two fade methods seem pretty scant for creating a new engine object but maybe there are other methods here and there that this new object could be their long lost home. And for the long run, surely more and more things will come up that will fit right into this kind of object.
Then again, you can forget all about my academic rants and just use Game.FadeOutUnfreezable()
