> I find the temporarily localized documentation idea quite interesting – anyone else here tried that?
I've done this a bit.
For several of my $DAYJOB projects I maintain documentation as Markdown files in the project, which get rendered into a website at build time. The project changelog is kept in version control the same way (https://keepachangelog.com).
Several times I've tried an experiment or alternate approach that didn't work out and done exactly this, complete with documentation, so the state is preserved. It's easy to document a prototype if it just means throwing a few paragraphs into a text file with the prototype.
Add a note in the changelog about adding the prototype then commit.
Make the revert commit and add a note in the changelog that you've removed the prototype.
Keeping a good, human-readable changelog as described above makes this strategy more scalable. You can document failed experiments you backed out, features that have been removed, and the like, in a few quick summary lines, keeping devs aware of them across the project's lifespan.
New devs can review it for the big-picture history and use the changelog's revision history to see what commits they need to see for the details.
Using a changelog this way also makes it reasonably possible to delete code but still remember it existed years later, something that's otherwise a surprisingly hard problem (especially if the project has high turnover).