Lots of those sound like reasonable ideas. It sounds like many of those could actually be stand alone systems. Your examples system, for instance, is something I have been planning on adding to the auto-documentation features that arc currently has.
It sounds like these ideas, and similar ones, can be broken down into three sections:
1) Auto documentation and help; Comes with arc for all functions and libraries. (i.e. tools like 'help, 'src 'fns, etc.)
2) Library loading system. Library meta-data, etc. Handles individual libraries and their details.
3) Web service for easy publishing and locating of hacks. Handles finding a hack, and the relationships between hacks on a global scale.
Part 1 can be done separately; it is rather decentralized and can be iteratively improved as it is not required by the others, nor does it require them. The more we work on it, the better a documentation system arc has. It can be worked on independently by multiple people. I will probably be spending most of my time working on these functions ;)
Part 2 and 3 require more standardization, and so need to be done with community oversight, but are still independent from eachother. I envision a library loading system similar to CatDancer's 'lib, that can work standalone like always, loading the new meta-data about dependencies, related hacks, history, etc. from a spefic internet location. Git might be useful here for keeping track of dev history, etc.
Part 3 more specifically would be a web service like news.arc, except it would be psv.arc, hsv.arc, or something. It would create a directory system for storing hacks, and support several apis and web hooks to allow people with proper authorization to publish and download hacks. It could be included with Anarki, and anyone could run their own hack server with minimal effort. This will probably be built last, as it depends on part 2.
With this web service, the functions created for part 2 can be extended to support the service, and find packages by searching a list of known hack servers. There could of course be an 'official' Anarki hack server, but it is just as well if we allow more than one. A centralized Anarki is practically an oxymoron anyway.
So, #1 can be done in place now, and includes extended documentation facilities, examples, etc, #2 is the structure for the library meta-data and the functions used to load it, and can probably be done in a lib in anarki as well. It may require it's own folder or branch. #3 is the web service, and probably the most involved of the three, and will require a separate branch or even repo.
