Sam,
your first explanation is fine describing a "single role" setup, but note that nothing has changed on that front between 1.7,1.8 and 1.9 with or without my patch.
It might be a good idea to re-read my earlier posts.
Note that things are tricky because you are rarely in a single role situation.
When you say
More specific definitions (e.g. at module level instead of course) usually 'win'.
We have to differentiate RA from RDef. Locality of RA is king (except for CAP_PROHIBIT). If you are "authenticated user" sitewide, and "student" at the course level, and authenticated user has X:allow, but student has X:deny, it's deny.
In my performance patches, I removed all importance from locality of RDef, but I now think that it was wrong. The patch that I am proposing brings it back, in the following manner:
When you have 2 conflicting RAs at the same scope, the locality of the relevant RDef wins. This is a bit cryptic, I think it is better explained in my earlier posts.
Martin L is proposing changing this so that role overrides take effect at the level where the override occurs
No.
See the example use case about block visibility that opens this discussion, and MD's proposal that failed to work. Might help clarify -- if not, let me know.
Edit: Sorry about the negative tone -- perhaps my explanations earlier in this thread are jumbled. This stuff is hard to explain and visualise...