While I agree with most of what @Zed is saying, I think “essentially beyond redemption” is too extreme a description of the now-“development” branch, so I’d be sad it if was just deleted entirely. I’ve been considering it a collection of incomplete “works in progress” which I might pick up and try to turn into something useful. So it’s been a useful source of stuff for me. I’ve picked up some stuff which never worked right, and some stuff which hasn’t worked since version 6G60 (over 12 years ago), and hacked it until it works. I like taking stuff which doesn’t compile and making it work, it’s one of the things I enjoy doing.
I mean, there’s still the even older i7/archive extensions collection, which I use for inspiration, but the ‘development’ branch stuff is usually somewhat more recent. It’s actually convenient for extension development to have a “most recent works in progress” collection, and I’d rather only delete extensions from it if (a) they’re completely obsolete because the functionality is now in Core Inform or has been directly supplanted by another extension with the same interface, or (b) they’re not license-clearable.
If people (such as @Dannii ) would strongly prefer that I “take over” and move the extensions which I fix into my directory, I can do that. I did this with Undo Output Control.
For a lot of them, though, I’ve just been making the minimal changes to make them usable, so I didn’t feel that it was appropriate to take over authorship as I would have if I’d made more opinionated changes. But I did want to update them enough so I actually could use them. And while I could have done that privately, I figured it made more sense to do it on a public branch so @Zed could see what I was doing (ahem!).
The Ron Newcomb and Aaron Reed extensions in particular have some extensive interactions with some of my own extensions (Neutral Standard Responses is a rewrite of Neutral Library Messages by Aaron Reed, which is based on Custom Library Messages by Ron Newcomb, and both of them wrote other extensions which interacted tightly with their own extensions) so I wanted them in a state where I could test the interactions.
Ability-to-test is the same reason I transferred the version-number-suffixed versions from the 10.1 branch for the Jon Ingold and Dave Robinson extensions, and for the ones by @Danni . For the Graham Nelson, Emily Short, and Eric Eve extensions I was just finding it a pain to get the copies of them separately – it is most convenient when I am developing extensions to have the “development” branch checked out and marked as an extra “–nest” to add to every inform build. Most of these didn’t need any actual edits, they just needed to be updated from the copies in the 10.1 branch, or needed the version number in the filename.
I already figured out that the Glk Foundations were going into Inform 10.2 (now 11) so I didn’t work on Glulx Entry Points, but I massaged some other Glx stuff into “compiles for now” format by making the minimal incremental changes for the current version of inform (mostly replacing glk() calls with named calls).
The new directory format for extensions is baroque, though understandable. Are there any plans to retire the very annoying .materials/.inform distinction? I really see no reason why this exists, although the rest of the format makes sense. I suppose I should discuess this on the inform7-evolution mailing list. In addition to making the minimum changes to get things to compile, that’s one reason I haven’t converted any of the extensions to this format during my update work; I was hoping the format would get some cleanup before everything is changed to it.