Strange role behavior?

System

I beleive we ran into this in 6.7.1 and it looks like it still exists in 7.3.2 as well:

I've been analyzing the workflow access to a workarea that we've secured to only work for a few users and processes.

We define an umbrella group Editor access at the top of a heirarcy of branches. Then we add a number of groups into that umbrella group so they supposedly have Editor access against all of the branches in the group.

We then set up workareas as group owned by a subset of the umbrella group. Even though everybody has Editor access to the branch, only the people in the 'shared by' workarea group can actually make updates.

Here's where the strange behavior occurs:
If I give a user/group Administrator access to a branch in this heirarchy, then they can perform a variety of functions against the branch and the workareas in the branch - this is as it should be.

Our workflow process that executes against this branch performs a number of tasks against a workarea in the branch that we really lock down so only the workflow (and Masters and Administrators) itself can actually modify the content in the workarea (we're using it as a pre-merge area). We've been having an issue where the workflow users can't successfully transition a certain task in that workarea as Editors - they need the Administration role to have the permissions to do so - but we don't want to give that Administrator access to the Editors.

BUT - if we assign those Editor users to an Adminstration role in a completely unrelated branch in TeamSite, they 'magically' seem to get the necessary permissions to transition the workflow task that they previously didn't have permissions for. They still can't perform any administrative tasks in the original branch that was having problems, but assigning them to an Adminstrator role -anywhere in TeamSite- is changing how they can interact with the workflow in the secured branch.

Is this expected behavior, or have we run into a strangeness/bug? It's a very subtle one.

Thanks!
Wally