We're talking about two different things. In your example you show a hierarchy of packages mounted in the site map. It would indeed be useful to have packages instances inherit the permissions of their parent nodes in the hierarchy.
I was refering to to the permissions themselves; 'read', 'write' etc. which can form a hierarchy (if you have 'read' permission then you have 'foo_read' because 'foo_read' is a child of 'read'), and also acs_objects (a foo object being a child of acs_group, for example).
Whenever you create a foo object from within the foo package, you also create an acs group, accessible from within acs-subsite, acs-admin or wherever. Because the foo object and the group object share the same object_id then any permission you apply to your foo also applies to the group. There is a forced inheritence of permissions backwards up the acs object hierarchy.
Sometimes you do not want to give users random permission ('read' permission means something different to each package, it has it's own application specific context) to the 'basic' objects of your new object type.
