quoting compat(5) on OSX 10.6.2:

<quote>
     Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel calls to conform to the SUSv3
     standards even if doing so would alter the behavior of functions used in 10.3.  Defining
     _POSIX_C_SOURCE also removes functions, types, and other interfaces that are not part of SUSv3 from the
     normal C namespace, unless _DARWIN_C_SOURCE is also defined (i.e., _DARWIN_C_SOURCE is _POSIX_C_SOURCE
     with non-POSIX extensions).  In any of these cases, the _DARWIN_FEATURE_UNIX_CONFORMANCE feature macro
     will be defined to the SUS conformance level (it is undefined otherwise).

     Starting in Mac OS X 10.5, if none of the macros _NONSTD_SOURCE, _POSIX_C_SOURCE or _DARWIN_C_SOURCE
     are defined, and the environment variable MACOSX_DEPLOYMENT_TARGET is either undefined or set to 10.5
     or greater (or equivalently, the gcc(1) option -mmacosx-version-min is either not specified or set to
     10.5 or greater), then UNIX conformance will be on by default, and non-POSIX extensions will also be
     available (this is the equivalent of defining _DARWIN_C_SOURCE).  For version values less that 10.5,
     UNIX conformance will be off (the equivalent of defining _NONSTD_SOURCE).
</quote>

If I read this correctly, this means that for deployment target 10.5 or later you must define _POSIX_C_SOURCE to get the correct version of getgroups, but that also hides all non-posix symbols in system headers. 

I haven't tested yet what the behavior is when neither _POSIX_C_SOURCE nor _DARWIN_C_SOURCE are defined (on OSX 10.4, 10.5 and 10.6).

BTW. It is possible to work around this by symbol renaming similarly to what Apple does in their headers to get the two variants of getgroups in the first place. But let's not go there unless there really is no other way.

As to your question "Why do you think this is what users expect to get when calling posix.getgroups()?": I'd expect that os.getgroups works just like it does in C code, and agrees with id(1). But then I'd also expect that os.setgroups affects the result of os.getgroups... Lame platform bugs are no fun :-(