If there are libraries only available with the v0.0-extended version,
then I propose to give them a version proper, compile them for the
architectures in use *today* and put that to Deken, along with an
objects file. IMHO, the original binaries should be left alone.
For a moment I thought you were saying "screw who needs those old externals", but now I see your point is different, right? :) Well, as someone who's working on a new library that offers many alternatives to unsupported/old libraries, I actually tend to think like that, but that's bad! I've seen people really frustrated trying to restore old extended patches that used more obscure externals, and I've seen them give up on Pd (all forks) or on vanilla for that.
Do you have any particular libraries in mind?
All of them, that's it! Let's get every object from extended listed and findable via deken with its corresponding library. Yeah, it's a dirty, lame and arguable job, but I think someone's gotta do it, and I'm game.
Now, if we'll leave the packages alone or have new versions, I don't know. I like the idea of making it clear that the library belonged to Extended and if it only has "v0.0extended" I don't really see the point in having a new version, but I don't really have a strong opinion on this.
One way or another, what actually brought this up was someone having trouble finding 'envgen' from ggee in deken, finding the one from 'jl' instead (which is not from Extended by the way). Now, ggee has a repository that you collaborated on =>
https://github.com/pd-externals/ggee So... yeah, you've already uploaded a new version of ggee to deken, so maybe you can get a new version or the object list with it?