So, it’s possible we’re both overthinking this and underusing the abilities of Git.
Perhaps the thing to do is to keep the repository folder structure more-or-less as-is but create a new series of BRANCHES. It’s possible to have a branch for each version. It’s possible to selectively pull changes from one branch over to another, selectively, though it’s a little messy. I’ve done it though, on other projects. “git cherry-pick” is the key to doing it cleanly.
The current “master” branch should probably be abandoned and renamed for political reasons anyway. So it could become the base of the “old-experimental” branch (containing everything, including stuff which never worked). Meanwhile live branches for “v10”, “6M62”, and “6G60” could be maintained – with the recommendation to newbies, in the README.md file, to be “check out the v10 branch”.
This would also allow for more specific v10.1 branches if that became necessary.
This corresponds with Graham Nelson’s idea of using git tags, but tags aren’t gonna cut it since updates to the v10.1 version may be necessary, so branches are the way to go.
In git, branches are cheap and porting stuff from one branch to another is relatively cheap. So I think this is likely the best way to go for maintaining different versions of the Extensions repo for different versions of Inform.
After thinking about it, this is what I recommend. First, update the README.md to explain the new branch structure. Then make “old-experimental”, “v10”, “6M62”, “6G10”, and “v10-upgrade-work” branches forked from the current master branch. Initially all the branches will be populated with everything. If Zed is willing, since he’s done the work to figure out which works where, then he can “git rm” the stuff which doesn’t work in 6M62 from the “6M62” branch, the stuff which doesn’t work in 6G10 from the “6G10” branch, the stuff which doesn’t work in v10 from the “v10” branch.
Set the “v10” branch to be the default one shown on the Github front page.
Then we can work on upgrading old stuff to v10 on the “v10-upgrade-work” branch, and when they’re ready (one at a time) add the revised versions of the extensions back to the “v10” branch.
Or we could just do the upgrade work on a single “experimental” branch, now that I think about it, and not have separate “old-experimental” and “v10-upgrade-work” branches. I kind of prefer separating “old-experimental” from “v10-upgrade-work” though