I've written a PHP website including a small CMS without seperating code and presentation. At all. ~3500 lines of code. It's the typical PHP site where the average PHP file consists of 50% code and 50% "echo" output commands. It has been running for more than a year now and I never had problems finding bugs or maintaining it.

Use aptitude.
apt-get remove --purge <package> to remove the config files.
aptitude purge <package> to do the same with aptitude.
Aptitude does what apt-get can't. It maintains constraints. So, if you install Package X which automatically installs Y and Z and then remove X three years later, aptitude will remove Y and Z, too.

Better advice: don't put your code in the web root.

From a security standpoint, you should get it out of your head that naming your file in a particular way somehow gives it more security. Just because one directory on the system is configured to execute files with a .php extension doesn't mean others are. Especially when those others lie outside of the web root: if someone manages to get access outside of that, they have bypassed Apache's configuration already.

In fact, once you leave the web root, I'd say the most likely path to hacking comes from the local machine: someone with access to the file system browsing around. In those cases, I'd wager that naming your files with .php would make them more likely to be found. If that scenario seems unlikely to you, then consider how unlikely the idea that a file outside of your web root is accessed in the first place.

As a side note, if it's outside the web root, protecting it through htaccess won't do any good, since it's outside the web root: Apache won't parse the file anyways (since Apache won't serve the file, though, it doesn't make a difference).

Now, since naming your templates with a .php extension gives them marginal security benefits if they're stored in the webroot, and doesn't cause any problems either way, why not do it anyways? For the same reason you use a for loop instead of a goto statement. Sure, both ways will work, but in the end one looks neater and tells you more information about what the construct does. Likewise, why not name all the image files on your server with a .img extension? Both ways will work, but in the end one gives you more information about what the files are.

Ideally, yeah. Then you simply have a single go.php file that you map your URLs to, and that file passes control to the application handlers which lie outside of your web root.

The simplest way to achieve this is using mod_rewrite. In this example I don't have the ability to change my web root, so I use mod_rewrite to mask it.

Then I use this mod_rewrite rule set:

RewriteEngine on
RewriteRule ^$ engine/Cx.php [L]
# Translate path into the webroot if not already done
RewriteRule !app/webroot/ - [C]
RewriteRule (.*) app/webroot/$1
# If file doesn't exist in webroot then use Cx
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* engine/Cx.php

The first rule sends the index page to my engine. The second and third rules translates paths into the app/webroot/ directory. The third rule checks if the given path (now translated into the webroot directory) exists. If it does not, it hands the URL to my engine.

Using this setup, I can place static objects into the webroot, and it will be clean of all code. Also, it is impossible^* to access any of the code.

^{* In any security discussion, absolutes such as "impossible" are assuming normal operation of the software involved, i.e. that there are no exploits in mod_rewrite or apache.}

of course it can, it can also use j#, or any other .NET language -- you can add your own languages of course (there are some wrappers that add LUA to .NET) -- and soon .NET will have ruby also ("IronRuby").

I don't really do anything with time zones, so I'm fuzzy here, but I remember getting an email from microsoft about their API operating differently now that the daylight savings times are different. So there is an API that handles time zones/daylight savings times that's built in -- I've just never used it -- or needed to.