Igor,
It was working as advertised before i setup the fastcgi_cache, using just plain fast_cgi. In the process of trying to debug this, I turned fast_cgi cache on and off, and that particular url worked when fast_cgi cache was turned off.

In addition, extra long urls that normally would have produced a 404 before i implemented fast_cgi cache did not produce a 404, and instead produced the same error mentioned above.

In performing more debugging, I realized that this only happens when the request should bypass the cache, using fastcgi_cache_bypass.

I'm also using the nginx_cache_purge plugin, which I will disable, test again, and report back to see if we can isolate this problem in that particular plugin.

In the meantime, one of these urls works, and the other doesn't, the difference being a single character:
http://alchemi.st/wp-admin/load-scripts.php?load=hoverIntent,common,jquery-color,schedule,wp-ajax-response,autosave,suggest,wp-lists,jquery-ui-core&foobar=asf
http://alchemi.st/wp-admin/load-scripts.php?load=hoverIntent,common,jquery-color,schedule,wp-ajax-response,autosave,suggest,wp-lists,jquery-ui-core&foobar=as

the error that I get is this:
[error] 4671#0: *17568 upstream sent unsupported FastCGI protocol version: 97 while reading upstream,

Take a look here to see my exact configuration: http://alchemi.st/2011/04/05/nginx-wordpress-network-and-fastcgi-cache-the-ultimate-guide/
I added a specific section to the nginx config as a workaround to this particular problem, however, without that workaround, the load-scripts.php script fails, as does any sufficiently long url that should bypass the cache.

What is baffling to me is that the wp-admin/load-scripts.php file should bypass the cache, as I have the wp_logged_in cookie set.

I will try this without the nginx_cache_purge plugin and see how things go.

Thanks again!