One of the first bugs that showed up after deploying the Xrandr GUI was pretty serious - gnome-settings-daemon crashed on certain X drivers (radeonhd and intel with i855 chips most notably, also fglrx and possibly nvidia). This was an unfortunate bug in that it prevented login. Fortunately, it was straightforward to work around - just disable the xrandr plugin for gnome-settings-daemon via gconf (/apps/gnome_settings_daemon/keybindings/xrandr)
Unfortunately this error has proven difficult to debug. The issue is that while several drivers support xrandr 1.2, they still crash when this tool tries to set up xrandr. So simply checking for xrandr versions via XRRQueryVersion() is insufficient.
I gather that fglrx has recently gained xrandr 1.2 support (at least, in tests using the xrandr command line tool, it accepts xrandr 1.2 syntax for changing screen size, but we got a BadMatch X error when doing so).
In the case of -intel i855, it's interesting that there have been no reports of issues on newer chipsets (in fact, it works fine on my 945 and 065 systems). The i855 and earlier chips have some unique bios issues that had been limiting people to use of -i810 until recently; it's entirely conceivable that there could be some remaining bugs particular to xrandr 1.2 support.
radeonhd is the most perplexing, since it advertises good xrandr 1.2 support. I found that there were a number of patches submitted to xserver by one of the radeonhd developers to fix various xrandr problems, but testing with those patches included did not change behavior at all.
I'm not sure how to troubleshoot this issue further. The most obvious next step is brute force - detect if we're running with one of these drivers or chipsets, and just avoid doing the xrandr calls in this case.
Unfortunately, xorg does not provide an interface for getting the driver name, but it can be parsed from the Xorg.0.log. I wrote a quick code to do this, which might be useful for other purposes.
I wonder if this issue might be related somehow to this bug?