I imagine this is more efficient & reliable than using ACLs on Smart Groups. (Which works... sort of.)

But the bigger issues when I've addressed tiered permissioning is Groups. Under your implementation, I'd guess that users can see & user any groups, though of course they'll only return records to which they have access. But then everyone sees everyone's groups, which can clutter up the interface.

Ideally, region1 users could create sub-groups to which only they would have permission. This worked well under the existing groups-based ACL system except for one very key oddity: having permission to create a group doesn't mean you have permission to see or use the groups you create. That still has to be explicitly defined by the super-admin. I wrote some very rough code to run in a Drupal block for the CiviCRM 1.x API. But it broke completely on upgrade to 2.0, and because of the problems with using Smart Groups, we opted to just open up the groups to all users anyway. I will probably rewrite it from scratch as an actual Drupal module for an upcoming project.

The code override option sounds really useful. I would strongly urge for this to also be implemented via a hook so that a path to override code can be set programatically by modules/components/add-ons, and not just through the admin interface. The admin interface could then simply list all modules that provide overrides, and let the user specify priority/conflict resolution - i.e., which modules wins if more than one provide the same file.