As stated, how a particular compiler allocates bitfields is *extremely* implementation specific.  There can be differences in implementations between different compilers, different *versions* of the same compiler, and different invocations of the same compiler where the options are varied.

I am wondering whether adding this feature will open up a can of worms that we don't want to deal with.  There are other options beyond MSVC and GCC that seem reasonable.  For example, GCC packs bitfields together on structures defined with '__attribute__((packed))'.  Do we need a GCCPACKED option now?

Also, GCC 4.4 fixed a bug that can lead to differences in structure layout from previous versions.  See -Wpacked-bitfield-compat option [1].
Do we need a GCC44 option now?

Finally, structure layout is architecture specific.  GCC for x86, for example, has the 'ms_struct' attribute extensions for x86 [2].  Does this mean that for a GCC compiled Python that the MSVC option will only work for an x86 host?

My point is that there are many, many variations on how a *single* compiler can allocate bitfields.  So just saying "GCC allocation"
strategy is not adequate.

So, lets take a step back.  What exact problem is this feature trying
to solve?  Is one of the use cases that 'ctypes' for a Windows hosted Python built with MSVC++ can interop with C code compiled with a Windows  hosted GCC (e.g. cygwin)?  If so, then is that realistic?  ISTM, that there are other ABI differences that would prevent that from working.

It seem perfectly reasonable to me that ctypes will only interact with bits that were constructed with the exact same compiler (and options) as the interpreter itself.  If it is not already, then we should document this.

[1] http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
[2] http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html