I disagree that the appropriate place to include that list is in some external object; after all, if member lists are sufficiently relevant for ad-hoc groups, why wouldn't they be relevant for identifiable groups? Giving something an identifier makes it more relevant, not less. It isn't a place to list everyone in a class (generally), but if there's a team of three people doing an obstacle course, the member list is appropriate whether or not there's a handy identifier for the team (perhaps the obstacle course is tracked by mobile app).

The simplest approach is to only query based on the group identifier or identifiers of members stated in the actual statement. There's no need to require they never have different member lists in that approach, either; the member list is, as discussed the last time groups were revised, not intended to be exhaustive, nor is it intended to suggest membership in the group at any other point in time.

So, for the language here, I'd basically keep it like it was before (including require anonymous groups not include identified groups again). The query section would mention that queries happen be over members of groups when the relevant property is being queried, and state that "LRSs MUST NOT consider Agents members of an identified group in one use solely because they are members of an identified group with the same identifier in another use".