The "Main Site Members" relational segment is created in acs-kernel/sql/*/acs-install.sql.
It could be created when "Registered Users" is created, but I chose to delay it until acs-install because this is where the main site is created and mounted, and where "registered users" is transformed into an application group referencing the main subsite's package id. Put all my kludges in one basket, so to speak.
I implemented this in 4.6. Before the main subsite had its own membership group so registered users didn't belong to the main subsite, which is wrong. aD had actually intended to copy registered users into the main subsite membership group: the 4.1->4.2 upgrade script did this but the registration code wasn't modified to track this change. I decided it made more sense to just make registered users *be* the main site membership group. Much simpler than copying users around willy-nilly.
The relational segment is in some sense redundant but doesn't cost anything as it's built on membership_rel as mentioned above - all the rows already exist for the relseg. Having this relseg around should make it easier to write general API stuff built around relational segments (such as subsite admins or other "role"-implementing relsegs)
Without it in some cases code would need to check the subsite membership group, other cases various relsegs rather than just be oriented around interrogating relsegs.
This is infrastructure that's largely unused at the moment though Lars has been doing some admin UI work for 4.6.4 ...
And yes, please use the Tcl API in acs-subsite/tcl to manipulate groups, relsegments, etc. If you need to do something that's not covered by the existing API and if that "something" is general enough, let's add it to the API so others can benefit.
And, Mr. Bob Phillips, I caught your code - your claims of being non-contagious while sputtering and coughing into our pitcher of beer notwithstanding!
