Can Nginx handle php (or similar fcgi) requests inside of an alias?

The solution provided here is not a solution. And it's not correct anymore. Using Lucid (10.4) I was able to use this solution. The problem with womble's solution is that it doesn't set the DOCUMENT_ROOT parameter properly; rather, it includes the script name in the document_root.

This seems to work OK.

location /foosite {
    alias /home/foosite/www/;
    index index.php index.html index.htm;

    location ~ /foosite/(.*\.php)$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$1;
        include /etc/nginx/fastcgi_params;            
    }                                                 
}

Using nginx/0.7.65

The "garbling" you talk about is, as far as I can tell, a bug in nginx relating to nested location blocks (or maybe aliases in location blocks that do regex-based matching without a capture... I'm not sure). What I was able to do, however, was fairly straightforward.
First, you can put all your fastcgi parameters, including the fastcgi_pass line and fastcgi_param SCRIPT_FILENAME $request_filename into a separate file for inclusion in the relevant parts of the site. I put mine in /etc/nginx/fragments/php.

Then, for /foosite, you need two location blocks, like so:

location /foosite {
    alias /var/aliases/foo;
}

location /foosite(.*\.php)$ {
    alias /var/aliases/foo$1;
    include /etc/nginx/fragments/php;
}

One thing to be wary of here -- unlike "regular" location blocks, it appears that regex-based matching runs in the order specified in the config file (not longest-match-first, as appears to be the case for non-regex location blocks). So, if you're doing a site-specific PHP location, as well as a generic "all-site" PHP handler (location ~ \.php$) then you'll need to put the generic "all-site" handler last in the server block, or all hell will break loose.

Yeah, this sucks, and if I get the motivation up I might try and work out exactly what's going wrong with the nested case (the config parser doesn't barf on it, so I suspect it's supposed to work but nobody actually uses it, so it's buggy).