I watched your video post the other day and I have a suggestion on how you should approach the “Reseller” issues you needed to address.
Consider putting them in their own domain now.
You have “Resellers” and then everything else. Rather than mixing Resellers into your data model, take a stronger approach into separating them into their own data domain.
That way you can treat the Resellers domain to all of the constraints you need to apply for whatever additional issues that they cause you and not need to consider how those constraints will affect everything else.
Then you are free to treat the Everything else domain the way you like to see it progress without worrying about how its going to effect Resellers.
This is going to be easier to administrate because you won’t be filtering relationship type when considering policies within the domain.
If resellers want to see something or don’t want to see something, it will only affect that domain and you don’t have to worry about how it effects the other communities.
This should be as easy as duplicating your data bases and deleting all the records that do not have a reference to resellers. Or only copying over data bases that have a reference to resellers and deleting the other records.
Administratively, you can see both domains, but they cannot see each other.
So if I am a member of the Resellers domain, I will only see the reporting available in that domain.
They can find it anyway would mean that I am a member of both domains. This gives me the ability to compare my membership rates. But also consider that you could split off another domain, and a member could join that domain, too, and then they would 3 rates to compare.
But they have to have membership in the domain.
I think that this gives you more freedom to develop the Everything Else like you want the freedom to do, and then create another domain when you have to apply restrictions.