On the 12th day of Christmas, my true love (SharePoint) gave to me, one-blog-per-day-until-Christmas #39. (Songs don't have to rhyme, you know...)
The Problem
Once you break inheritance on a securable object in SharePoint, that inheritance is forever isolated from the parent, making it very difficult to manage security additions that are intended to flow downwards. Yet often breaking inheritance is unavoidable, as individual security rules cannot be set or changed at a lower level - it's all or nothing, man.
For example - List "Christmas Gifts" is secured to and can be read by Bob and Jo (though of course, you've used groups in real life haven't you!?) Item "Bob's Christmas Gift" has inheritance broken so that only Jo can read it. But if Thomas comes along and is granted access to read the list "Christmas Gifts" also, he won't by default by able to see "Bob's Christmas Gift".
Compare and contrast to the file system. Bob and Jo can access folder "Christmas Gifts". Bob is denied access on document "Bob's Christmas Gift", so only Jo can access it. Thomas is then given access to folder "Christmas Gifts". Because he isn't denied at the lower "Bob's Christmas Gift" document level, he'll be able to see that as well.
Not sure about you, but I find the latter much more flexible and intuitive.
Possible Solution
Make SharePoint security inheritance like file-system security inheritance, or at least add the option of "break inheritance and stay broken" vs "merge inherited rules" or similar.
All of this would require the abilty to explicitly Deny privileges, which can only be done through security policy in Central Adminstration (AFAIK). I think it would be flippin' useful.
Workaround (For Now)
Plan your security structure very very carefully to minimise inheritance breakages, including extensive use of groups. Perhaps try
something like this free access checker web part to improve visibility - or
something more comprehensive.
:) Matt