Can you demonstrate a use that wouldn't be better served by a separate subroutine?

Well thats a good question, and maybe is actually the right way to go.

The idea is that isApproved can handle all of our access control requirements. For instance a typical scenario is something like

if ($validtype{$NODE->{type}{title}} and
    $DB->isApproved($USER,getnode('sitedocclan','usergroup'))
) { 
   ....
}
[download]

Which to me should be simply a call like

if ($DB->isApproved($USER,'sitedoclan_editable',$NODE)) {
...
}
[download]

where 'sitedoclan_editable' would be a user group containing an accessrule and sitedocclan. The accessrule would enforce the node level logic, by returning 0 is the $NODE's type was not appropriate, and by returning undef if the node was of the appropriate type it would allow the usergroup logic to make the final decision.

Now you might be thinking ok, well then why dont we have a routine that does this without changing the behaviour of isApproved. The answer I would offer would be that to provide the flexibility and power available from the proposed isApproved() behaviour you would essentially have to recreate the same scheme anyway, so why not just unify it in the first place.

The trick is to stop thinking that isApproved is about doing membership checks, but rather to think of isApproved as being an access control mechanism, ie SDC not being able to edit superdocs is basically the same thing as a non SDCer not being able to edit sitedoclets.

The other nice advantage of knowing the $NODE is that it makes it possible to come up with a framework for automatically providing the appropriate code for rejecting a user.