It would be really helpful if we could specify a unique "friend" or group of "friends" for each method in a class, rather than a setting that applies to all members of that class.
Details: Access scope is defined at the library level. LV R&D discussed alternate scopes extensively in the library design and concluded it was technically quite hard and of minimal use to users. I spent multiple years checking that theory in my own code and in the code that I surveyed from customers, and it bore out: most libraries that use community scope have a clear and obvious purpose for their one use of community scope. The ones that have two uses are generally one app use and one testing use, and which functions are intended for which use are easy to identify from VI name, so there's little confusion for users of the library.
Now, having said that, you may be one of the few users who would find it useful, but you are in the deep minority (community scope is already quite rare) -- so rare that I have no qualms declining this idea.
If you want to more tightly restrict a library's member VI, you can create a sublibrary that only has that one member VI. Obviously you cannot do this with members of a class, but you may be able to split the class into two halves in some cases.
