Resetting during a save would make the full-game run faster, if the resulting glitchy state were used for something other than immediately ending the game. However, this would presumably be disallowed due to the full-game run being, effectively, "no game end glitch", as we typically disallow suboptimal uses of glitches. So "no reset during save" is the only thing that makes this category different from the regular game-end glitch category, and it would not have an effect in any other game-completion category (because game-end glitches more generally would be banned).
Overall time saved with these calculations is 00:03.58 seconds of gameplay, or 9 seconds 19 frames of IGT.
But overall I do get what you mean by legitimacy, and I'll add another thing to the legitimacy question, since the save glitches TASes use checksum collision, they also need to use a subframe reset. Particularly, my submission requires a reset that only has about a 60 microsecond window to hit. While this might seem okay on face value, you then realize we can't programmatically reset the console, and the reset has to be done by a human... To be clear, the RTA WR of Crystal had a much bigger window to hit, about 3 milliseconds, which is fairly viable for a human to hit. 60 microseconds is insanely small, it's probably possible to hit, but you might as well just flash the expected save data to the cart after the reset for a possible console verification than spend many days to hit that tiny window. Which even then that is flawed because RTC can possibly just screw you over. So I'd find it somewhat unlikely that the save glitch TAS can be console verified (which I assume would be the objective measure to what's legitimate), at most in theory it should be possible.
The goal of our movies is to show what could theoretically be done on a real console.
An in-game task or puzzle that is meant to be accomplished or solved by a human while playing the game, by sending inputs to the game and getting its reaction.
But after you've seen it a few times, watching it again becomes as entertaining as doing nothing.
As a result of the above, simply going through all the menus fast does not hold any superplay value, because it's identical to checking out every menu item on a DVD, except there may be something of artistic value on that DVD, while this game exists for purely technical purposes and only allows you to test if your console is functional enough to pass all tests.
Probably relevant: http://tasvideos.org/Nach/HistoryOfGamesAndRelevanceHere.html
For what it's worth, I think the fundamental difference between reset-during-save runs and the Coin Case run is one of legitimacy. The Coin Case glitch is, IMO, obviously legitimate, and it is the fastest category which is obviously legitimate. Meanwhile, reset-during-save glitches are more debatable with respect to legitimacy, as they cannot be accessed entirely using controller input. (In a way, this defeats the main goal of a TAS, which is to beat a game entirely with controller input, no cheating or hardware modification or anything involved.) If I remember correctly, Pokémon disables the reset chord (A+B+Start+Select) during a save, thus the only way to get a save-glitched run is to cut the power to the console (e.g. using the physical power switch on a Game Boy Color). The game also outright tells you that doing this is a bad idea, implying thtat it can corrupt the game. So I don't think the "save glitch" is actually a glitch at all. It isn't something that the programmers failed to think about, and it isn't something that exploits a mistake that they made when programming. It's basically a case of using the game's power switch (not the controller) in a way that the developers were aware was possible, were aware could break the game, but were also aware that they couldn't guard against. If anything, it's an exploit of the console rather than the game (because the console gives the game no way to override the behaviour of the power switch). TASvideos has historically allowed runs that rely on oddly timed physical resets, but there's a case to be made that it shouldn't (and to me, it isn't interesting to see a game being beaten like that, because it's basically an exploit that I would expect to exist in any given game because there's only a limited amount a game can do about unless it greatly increases its SRAM usage). That argues that "fastest run without abusing physical resets" should be a legitimate category, probably more so than the fastest run that does.
For what it's worth, the category of this run should be "no reset during save", "controller input only", or something similar. What matters in terms of obsoletion is not which glitches are used, but which glitches are not used.
Personally, I just see save corruption as dull. It absolutely has technical merit, but since it showcases so little gameplay, I think there should always be space for a NSC run to stand out, even from an entertainment perspective: most viewers may not be sated after a 3 minute run and want to see more. I also don't think it's difficult for people to see the technical difference. Forget infosec, everybody knows you shouldn't turn off the power while saving! It's far more straightforward to explain than ACE, that's for sure.
It really feels like interest in CCG as a whole is waning, at least in terms of people on the site.
Going back to the first quote and the previous standards I brought up (SMB3 and Chrono Trigger), "game end glitch" is generally treated as a universal category despite what methods are used. Save corruption or no save corruption, both runs get to a point where they manipulate memory to reach the credits instantly. My arguments are upholding how the site has historically handled (coin) cases like these.
