It's so cliche to recommend a more complex tool --- with its own associated learning curve and more complex failure modes --- when there's already a simple method that works perfectly well, but isn't "best practice" or whatever the dogmatists call it.
Can you run two or more versions and compare their behaviour simultaneously, even debug them side-by-side? I'm sure there's some sort of plugin and IDE ecosystem that you can spend tons of time learning how to configure just to be able to do that, but if all I need to do is to copy the files and rename them, why not?
Do some people really love excess complexity so much?
I guess it depends on your use case. If you have a basic tool where most of the functionality lives in a single file and which you need to compare to previous versions frequently, I can see how just having incrementing file names could be useful.
I would say that this is a bit of an exception though. Most projects are spread across many files and dependencies, so it would be a huge mess trying to manually version those by renaming files all the time. I also rarely want to compare several different versions of my code side by side, so I prefer having all of the old stuff 'hidden away' in git by default.
So to me, git + a sensible IDE is actually the less complex option, by far.
I agree with the general gist if your post, but still wanted to call out the "git worktree" because that would solve the problem you're describing. It's pretty much a better version of cloning the repo twice.
Can you run two or more versions and compare their behaviour simultaneously, even debug them side-by-side? I'm sure there's some sort of plugin and IDE ecosystem that you can spend tons of time learning how to configure just to be able to do that, but if all I need to do is to copy the files and rename them, why not?
Do some people really love excess complexity so much?