32 and 64 bit interoperability on 64-bit Windows

Is there a good thorough authoritative reference that discusses interoperability between 32-bit and 64-bit processes? Based on googling I have deduced that:

A 32-bit DLL can only reside in a 32-bit process, and a 64-bit DLL only in a 64-bit process.
32 and 64-bit processes can only communicate using loosely coupled message systems, such as network communications, which means they can communicate using COM/DCOM.
32 and 64-bit COM components have different registry entries. A component is typically only registered in one of the two and typically only seen in one of the two worlds.
A 32-bit process can only create something registered as a 64-bit COM component if it uses CoCreateInstance with the 64-bit invocation flag, or (and I am guessing on this one, is it possible?) if the 64-bit component is somehow registered in the 32-bit registry but under the hood is still created as an out of process 64-bit process, or if there is a 32-bit shell COM component which creates the 64-bit component and then redirects calls to it?

This suggests that: 1. A 32-bit application can not use GetObject to get hold of a 64-bit version of Excel that is running? Or can it? How is the running object table (ROT) impacted by 32 versus 64-bit issue? Can a 32-bit process create an instance of Excel if only a 64-bit version of Office is installed? I would think the answer would be "no" unless the 32-bit process uses the 64-bit flag in its CoCreateInstance call, or if Excel somehow registered itself in the 32-bit world as well?

Does Microsoft automatically do anything like having CoCreateInstance from a 32-bit process check the 64-bit registry and try to create an out of process 64-bit component if there is none registered in the 32-bit registry? I have seen some release notes from 64-bit Office where Microsoft warns about access from 32-bit applications to 64-bit Excel not working, yet I know of one instance where it seemed to just work.

Is there a good technical factual reference for this?

It is explained quite well in the MSDN Library docs for CLSCTX. Lots of rules, the default behavior is:

If neither the client nor the server specifies a preference, then:

If the computer that hosts the server is running Windows XP or Windows Server 2003 without Service Pack 1 (SP1) or later installed, then COM will prefer a 64-bit version of the server if available; otherwise it will activate a 32-bit version of the server.

If the computer that hosts the server is running Windows Server 2003 with SP1 or later installed, then COM will try to match the server architecture to the client architecture. In other words, for a 32-bit client, COM will activate a 32-bit server if available; otherwise it will activate a 64-bit version of the server. For a 64-bit client, COM will activate a 64-bit server if available; otherwise it will activate a 32-bit server.

Check the MSDN article if you want to override this behavior.