Very helpful response from Andrew Arnott, who maintains the open source OpenID library we use:
Google Apps for Domains doesn't use the OpenID 2.0-spec compliant method for discovery on an identifier. They have their own proprietary mechanism that they would like all OpenID RPs to add support for. Google says it's a temporary mechanism until OpenID officially adds support for what they're trying to do. But the implementation is scary (to me). Basically you turn over identifier discovery entirely to Google, before performing your own discovery, and if Google claims the identifier as one it controls, you have to trust Google. So basically Google becomes a single-point of control and security. Personally I think that flies in the face of OpenID and the security that comes from having independent OPs. So, suffice it to say I haven't added support for it to DotNetOpenAuth.
Now, the fact that this guy is typing in a longer OpenID that just his google apps for domains URL suggests that since his is a paid Apps account, perhaps Google is offering a more standards-compliant way to do it, and perhaps there's a genuine interop bug somewhere. I can't tell because I don't have a paid Apps account myself, but I'll talk to my contact at Google and see what the possibilities are here to solve the problem if there is a bug.
Regarding the "feature" of turning discovery over to Google in order to support Google Apps for Domains customers, if there's sufficient interest in supporting it, I may write an add-in module for DotNetOpenAuth that provides support for it, but I doubt it will ever ship with the standard library because I disagree with the idea. When OpenID > 2.0 specs out the standard way of what Google is trying to do, then of course DNOA will follow.
I'll let you know what I find out from Google regarding this paid Apps account.