Cooperating Node Access modules (CoNAc-patch)

Out of the box Drupal perfectly allows you to use more than one node_access module. The problem however is that the vote of each module is OR-ed with that of the others. In other words, access to a node is granted if just one of the modules says 'yes'. The system does not care if maybe one of the other modules would have liked to say 'access denied'.
There are a couple of attempts by various users to tweak Drupal to make this system more flexible, but most of them either got stuck somewhere, are a tad too complicated to understand, or simply do not work.
Recently I tried the patch that is described in http://drupal.org/node/196922. Although the issue is tagged Drupal 7, most of the discussion there is about Drupal 5. That specific patch however did not work for me, maybe due to the fact that it was way to complicated to configure in my opinion. So I decided I could do better and started rolling my own patch.

The CoNAc-patch

This patch modifies the node.module in such a way that the administrator gains control over how the votes of the different node access modules are AND-ed and OR-ed together. This way we get a Cooperating Node Access (hence CoNAc) structure.
In my particular case I have Taxonomy Access Control and the Workflow modules installed. TAC comes with one node access realm, term_access, and Workflow comes with two realms: workflow_access and workflow_access_owner. I wanted the system to grant access to a node when both term_access AND either one of workflow_access or workflow_access_owner said yes. In other words:

grant access if (term_access says ok AND (workflow_access says ok OR workflow_access_owner says ok))

And this is just about the way you have to specify it in the CoNAc-rule.
There also appears to be the 'all'- realm. I am not entirely sure where and how this could be used, but I'd better take it into consideration when specifying the CoNAc-rule for my situation:

all OR (term_access AND (workflow_access OR workflow_access_owner))

This rule is then converted to a nifty SQL-grants clause that is used in most of Drupal's SQL code when querying the node_access table.
The way this SQL clause is written not only takes care of the node access querying, but also gets the pager code right, fixing the problem described in http://drupal.org/node/264092

Please note that each node access module has to give an answer. In TAC for instance you can specify 'ignore' for a term/role combination. While this is perfectly usable when calculating access within TAC-only when you have multiple terms added to a single node, the ultimate answer from TAC however should be either access granted or access denied. Ignore is treated as access denied.

Warning: I'm not running this patch on a production site yet, but my tests seem to indicate that it works like a charm, at least with the above mentioned node access modules.