Here's my spin:
The APM is far from ideal. If one were starting from scratch, one might hope to do better (though for a first effort by folks who'd never done anything like this before, it's not bad).
We have *many* important issues to think about in regard to OpenACS 4. IMNSHO (NS=not so) there are issues that make the toolkit, as it exists today, close to unusable. Look at some of the threads regarding performance of the bboard system. Look at the three new threads on admin UI. Think about the private laundry list I've been building that I'll spring on the community after we hit a solid beta release and can start thinking about a second release cycle.
If I start thinking about prioritization of effort, rewriting the APM is way, way down the list. Tweaking it within its current framework will be necessary, for sure. But rewriting it into something like the BSD Ports system? This is a non-trivial task ...
In practice, it's my intention that our releases include "clean" versions of all packages the community supports, in a single tarball. My guess is that the vast majority of users will just use the tarball, and totally ignore the fact that you can download APMs individually.
People who want to stay up-to-date will, as suggested, are probably as likely to visit the CVS repository as anything.
This is one reason why I place "replace the APM" at a low priority.
Note that I'm not saying it would be a bad idea from an idealized ivory-tower vantage point. I just can't see it being important enough to deserve our putting resources into replacing it with something better for many, many months.
If you're looking for an opportunity to help ... we can give you work. Lots of work. That's no problem :)
