Just to be clear, I was agreeing that it might be "worth an experiment", and pointing out that you could avoid using PHP-CGI with the workaround I linked you to. That's considerably different than saying that "PHP will still work on remapped dirs", particularly when "work" means different things in different contexts. There could still be permission issues involved, and mod_php runs as user dhapache.
I can't say whether you can duplicate that or not using mod_php on DreamHost (I just haven't used it that much in quite some time now); you'll have to test and see if php (mod_php running as user dhapache) can write to that directory with out you opening the permission too much for good security.
I'm having a hard time making sense out of that question, but the general answer is "the actual path to the file" (ie. /home/user/dir/file_where_scripts_live) - though understand you may need to do this with scripting rather than "linking" to an url (the urls are likely to be impacted by the remapping).
Without review your whole site structure and script interaction I couldn't begin to tell you - the fact will remain that using different users may introduce permissions related issues (maybe with "reading", but most certianly, IMO, with "writing") that could result in you having to give "world" access to files/dirs so that dhapache can play (due to running mod_php - because PHP-CGI is not supposed to work). Note that one of the reason PHP-CGI won't work is this very permissions issue, and these permission settings are important for everyone's security on a shared host.
I looked at your example url, and viewed source to see how you were linking to c2.php, but I can't really tell what is happening. Maybe someone more "prescient" than I can tell.
From my experimenting, it looks to me as if there are some mime-type issues, at least, with c2.php (try just running c2.php directly). When linked from "outside" taptotal.com (as in this posted link), you get the "No Hi Jacking" GIF, but when directly pasted into your browser with taptotal.com as the referrer:
... it "runs" but doesn't display the image in FF . Now, with taptotal.com as a referrer, just try to browse:
(dammit - this forum "munges" code, even with the [pre] tag in use)
My results indicate the script is gagging on that img src tag attribute string with the html entity (can't parse the parameters to correctly read/pass the digit and width variables) Compare it with the url I linked in the preceding paragraph, note the replacing of the " % 26 amp;" (intentionally munged to trick the forum software - see the pastebin link) with an actual "&", and compare the resulting output.
It looks to me like the c2.script is running, just that it is broken in how it is linked and your environment has a mime-type issue retuning the PNG - but it's your code, and I'm just experimenting.
If I were trying to sort this, I'd concentrate first on getting a version of PHP to run a script in zzremapguy's directory. Probably just a phpinfo script, so I could inspect the actual environment more closely.
Assuming I could do that, I'd dig into C2.php to see if I could get it to operate when "called", linked, whatever, and get it outputting to the page appropriately.
From there, I'd evaluate how I might go about implementing it from within your file structure.
Frankly, I'd approach the whole problem in a different way, maybe I'd give users their own dub-domains and be done with it, or put a "manager" script in place that let me manage all their "websites" as subdirs under my user with them managing their files (upload, rename, delete, etc.) via a filemanager. I'd use the "Dreamhost supplied" counter and formmail scripts just to make it simpler.
Just as a test, I'd also try to run DreamHost's supplied counter from that dir, and see if it works (I'm thinking it won't, but who know until you try it, right?) That takes the whole PHP issue out of the equation and just confirms whether or not you can run a cgi script at all from the directory (remember, they say you can't - so I really wouldn't expect that to work).
I also would never give these "sub users" the ability to run scripts on my shared hosting account, as I perceive that to be just too risky (they may not do anything deliberately malicious, but they could inadvertantly still screw things up for me) - I understand that YMMV on that.