Simply deleting (managed) application directories using the filer is completely incompatible with the way RiscPkg works. What if something else depended on that application being present (because it provides a command-line tool, for example)?
There also seems to be an assumption that applications and packages are isomorphic. I can think of at least one major application (GCC) where this has been untrue for a long time - and if anything my preference would be to distribute in smaller chunks, not larger ones.
(A good way to think of RiscPkg is as a network administrator who provides a read-only share. You have limited control over what is in the share, but you can choose which bits of it you use, and you can make local copies of applications you want to hack around with.)
A system along the lines being described (an 'application updater' rather than a full-blown package manager) would no doubt be useful to many people, but the approach fundamentally different from RiscPkg. If anyone wants to write such a system then they have my full support and encouragement, but it really is a different project with different goals.
(The same applies to less radical variations. RiscPkg is GPLed and the back-end is LGPLed. You can take or leave as much or as little as you like.)