Groupings were introduced in version 1.8 as a way to organize groups within a course. However, groupings do not have any practical use in version 1.8 or current 1.9 (HEAD). As in 1.8/1.9 Groupings are more a useless complication than a useful feature. To be productive Groupings must be USED by activity modules. I have proposed a whole new range of groups/groupings features combining the design goals (but not yet implemented) of OU and the implemented version of Groupings working at ULPGC. The spec proposal may be found at http://docs.moodle.org/en/Development:Groupings_and_Groups

At this stage I will concentrate in two new features:

a) Making possible to use different groupings by different activities.
Activities can declare a grouping to use. This means that when that particular activity is set as visible/separate groups, the particular groups used are those belonging to the declared grouping. Hence, we can have simultaneous activities where users are distributed according to different criteria, activities & resources may be targeted to different audiences.

The needed changes are adding a field "groupingid" to the courses and course_modules tables to hold the grouping that the course itself or each module instance will use when set in visible/separate groupmode. By "using grouping" I mean that grouping-aware functions should operate nor on all groups associated with a course but only those associated with a grouping. So, you may have a forum declaring a grouping and thus using a particular set of groups. At the same time other activity in the course, let say an assignment may declare other grouping and thus treat the same users as distributed in a completely different set of groups.

"Use grouping" must be added to the configuration form for each module instance, parallel to "groupmode" attribute. Best way is to add to te common module settings

Module code must be adapted to ensure that $cm->groupingid property now existing is passed to groups-API functions within the module code to return/manage only those groups belonging to the declared grouping.

b) Group-based content delivery
Once each activity, and resources, may declare a grouping to use, it is possible to make that those users that are not members of any group of that grouping cannot access to the module content (being it an interactive activity or a Resource module instance)
A simple checking for group membership at the beggining of the view.php file for each module would do the trick
Group-membership may be checked at course page (function print_section() ) to make links to forbidden modules invisible to users without suitable access.

At ULPGC we have a test site with these features ENABLED, that is, already coded. You may find it at http://moodle.ulpgc.es/moodle19ulpgc/course/view.php?id=3
Try login as user "prof01", "prof02" or "estudiante01", "estudiante02" ... with password "moodle" for all

The file attached is a unified diff against HEAD that can be used to explore proposed code changes.