My setups (8 of the 9 I have here): php.exe (whichever one I'm using is named 'php.exe' in all cases, whether cli or cgi) is in the same directory as php.ini, php*ts.dll, and the external shared libraries (e.g. libmysqli.dll) needed to support whatever extensions that particular version of php needs. For users it would probably be better to put those kinds of .dlls into system32 or an equivalent path, but I find it harder to keep track of them that way.
I have no clue why Nuno reports that it does not work for PHP 5. Probably the clue's in 'set PATH'. There's no reason to set PATH unless you're doing something very strange with PHP. I don't have any PHP-related environmental variables set. The php-specific shared libraries (e.g. php_mysqli.dll) are in the same directory as the executable OR below it in a dir specified in php.ini, in 8 cases. I also have a php5 executable and php5ts.dll running as part of cygwin/bin - that's number 9.
I have both PHP 4 and 5 versions of cgi running with Apache (switch between them depending on what I'm doing), with PHP-GTK, as cli and as testbeds. No conflicts.
This means that if we suggest people to replicate the PHP 5 package structure with PHP 4 (move the contents of the dlls folder and the sapi folder into the root PHP folder), and place php.ini there, then that should work without and special PATH settings either for PHP 4 or PHP 5. I wonder why this is not working for Nuno, it is/was hard to beleive...
I don't really see, why you suggest that people might be happier with moving stuff to system32. I see just the opposite. It is also harder to remove PHP that way. BTW I wonder why the installer moves stuff outside the PHP folder then...
Goba