How do to deal with permissions and CRM field sets...?

This is a specific use case we're facing:

Our student worker Alan has created an "Individual" party. This individual is a member of the congregation. Using fields he was able to add the ability to store the individual's name, e-mail, phone number, what "serving area" they were interested in and if they wanted to join a "grow group". Grow groups are mid-week bible study groups. The plan is to have a laptop open on sunday so people could fill out all this information themselves directly on the computer, they would also be able to fill this information out themselves if they signed up on the site.

However, once they have said that they would like to join a grow group they are assigned one by someone else (call them a "manager" maybe). This is a drop-down field as there are a select number of potential grow groups. Once they have been assigned a grow group this information is publically available for everyone to see, its just only managers can change them.

So what is this?

Currently we're making "grow group" and "individual information" as 2 seperate profile2s. As Profile2s are seperate entities we can easily set the permissions on each one and assign them to certain roles. However I feel that this is diverging a bit from the purpose of profile2 and it becomes an interface that is ok for site builders, but now much more complicated for an end-user like Alan to do himself.

I realise that in this case grow groups ought to probably be some kind of entity or group in their own right. But I think this case represents well the use case of wanting to create information that has permissions that are different to other information on the same page.

• I have been thinking about genus or hat. But really this isn't something solved by them either? In this use case everyone has a congregation member hat. Here they also have the "Individual" party type. So assigning permissions based on hats or party types won't automatically solve this (although maybe in the create hat ui there might be nice ways around it).
• Do we make a generic permissions fields module where every field could have different permissions? I think there might be scope for drupal doing this but I think that would not be a nice way to solve this particular issue as I could imagine it being quite unweldy for large CRM databases.
• Site builders could easily deal with this. Do we just make it so we don't expect end-users to be able to add their own fields? Kind of feel this takes away from some of the awesomeness of even trellon's CRM now.
• Maybe we could keep everything as they are but create a nicer UI for dealing with permissions? Contextual links?
• What about making something like "profile access types"? I could assign a profile to be "public" or "private" and site builders to set up what particular types there are and then how permissions interact with those types. Something feels dodgy about this to me, can't pinpoint what but its kind of inspired by drupal's roles.
• Do we want to use profile2s to handle these things. Would it be more ideal to have a more generic "field sets" module that presented these groups to profiles2 and then built a UI for easily adding them
• We could use our tab interface. Say that different tabs have different permissions and just decide to not cater for this case.

I'm still uncomfortable with how we (me and rob) are suggesting to use profile2. It feels like we're moving away from using profile2 in the way it is intended, but I don't know for sure why I think this.

Any ideas?