I'm not sure if this is quite it... you might want to look into the "facebook bacon" setup, for some cross-domain privacy-out-the-window goodness.

There are very very good reasons for the limitations, Andy. I think Tony was being facetious. When you make a request of a different site, that opens up your site for whats called xss or cross site scripting. The other domain, if its not under your strict control, could hijack your webpage for their own nefarious ends (Malware, popups). What you could do, is have an XMLHttpRequest call to YOUR domain, and have the server contact the other domain. Its significantly easier to do it that way, plus, if its a common action, you could save bandwidth by only contacting the other server once, and using the results multiple times.

Here's an example of what I'm trying to do.

Computer A visits a page hosted on server B. The page's javascript (on A) will then make a client side request to server C and receive a string, and use that string to load the rest of the page.

I've come up with a hackish solution that works quite well (no unfortunately javascript does not have whatdotcolor, though the hack does have to do with graphics), but I'd rather not use it given the choice.

This is just the point: you should NOT have that choice. It's actually a security feature.

Why is it impractical for the request to go as follows?
A --XHR--> B --something--> C --something--> B --XHR--> A

That's the standard design, and it generally works quite well (plus, as noted, you can cache responses for better bandwidth usage).

If, however, you are trying to access a piece of server info, like, say number of diggs for an article, then there should be a signed api to use that ends up not using XHR.

with an iframe, you can't access objects inside it