they may even hurt.
I'm assuming you are referring to the maintenance and backward compatibility that is required as soon as you have libraries. Plus good libraries can be had even in bad languages - so it's not a good reflection of the language. Are you suggesting libraries should be a completely separate project with potentially many choices? The problem with this can be seen in Scheme. It's hard to move from project to project (job to job) when they use different implementations and those related libraries. Learning the related core libraries is often not worth it; if the scope of the project is small. Invariably libraries do not transfer well - maybe that is the problem that needs to be solved... Even with formalities like R5RS or R6RS core libraries are still implementation specific.
Plus, arc is suffering from an absentee benevolent dictator.
... You are missed over at the arclanguage forums. (http://arclanguage.org/item?id=8462) Specifically some direction for those of us that enjoy writing arc would be great. There are plenty of people that know and write arc - why not put them to work. What is your opinion of the community version of arc (http://github.com/nex3/arc/tree/master)? Do you use it? Is it blasphemy? Is this all just a giant social experiment to see what will happen to the language and community given no leadership and x-number of years?