If we have a hierarchy like:
content_revision->image->wp_image_attachment
I'm unlikely to want to add "content_revision_read", "image_read", and
"wp_image_attachment_read" permissions to each object just so I can allow a
user to see my wp-specific type data ("where to display this") while
simultaneously hiding the image the package wants to display!
No, you're not, and you don't have to. You apply the permission, whether package specific or generic, to the object_id you're interested in, your wp_image_attachment. You can now ask the question 'Can I read this WP Image?'. No need to apply permissions, of whatever sort, to any of the base objects.
If all the base objects use package specific permissions then all you've done is give some permission to an 'atomic' wp_image_attachment. If the base objects use generic permissions and so have you then you've given that permission to the wp_image_attachment AND all its base objects.
Do you care? Depends. In your case, probably not, but I don't know ... a content item and an image are objects in their own right, they'll show up in any CMS interface at least. I don't know what read, write and admin mean to the Wimpy Point package but they mean something else to CMS.
The danger of this being a problem increases with the length of the inheritence hierarchy (obviously...) and the more 'high level' the objects that you're defining, so I think this will crop up more when building real websites based on the base infrastructure people are working on now.
