I've mentioned several times that sort_key hierarchies could be moved into a separate table, and used as a mapping table. One advantage would be that you could create more than one security context for an object (or more than one of any type of hierarchy). This would allow you to add a "parent" object for all news items and use that item for permissions, while the package object would be on the same level, but not related to the "news admin" security object.
So, in my opinion, the problem is with the limited implimentation for the security context, which only allows a single hierarchy. There are still a lot of things to consider: would you need separate hierarchy and hierarchy type tables, so you could find all the "security" hierarchies, or would you store the hierarchy type in the mapping table to avoid extra joins?
After posting yesterday, I realized Lars must mean a change in the permission proc. I think another, simpler alternative is to create a special object and use permissions on that object as a proxy for "admin on all news objects". This could be setup as a package parameter, couldn't it? This is much more flexable, and you could wrap it up into a proc. There is no way to enforce future applications will honor any permission checks, but this has always been the responsibility of the developer, which seems like a good thing.
