While on this theme it might be a good idea to consider the different deployment scenarios, their merits and how does that change the configuration. For example:
In shared hosting: drupal/core drupal/local drupal/index.php drupal/.htaccess
No, it is like this: public_html/ public_html/.htaccess public_html/index.php public_html/drupal/ public_html/drupal/core public_html/drupal/local Then the admin can put: public_html/files public_html/somethingelse As long as they are outside of the drupal directory. This way, the index.php is in the public_html directory of the account, and .htaccess affects how it works.
Custom (non-distribution) unix install: (in /usr/local)
lib/drupal - equivalent to core above var/drupal - equivalent to local above
var/www/drupal/sites/example.com/files - this is configurable anyway
lib|var/drupal are not in the web-server's display paths, this potentially makes sharing the same web-server location with other apps easier
I think this is a bit overkill. We do not do this now, and it works fine for both shared and dedicated hosting. The admin of such a system can do all the tricks he wants separating filesystems and such using symlinks.
windows based installs: I'm clueless there
The changes to the current drupal are minimal, mainly in the multi-site file include code.
Apropos. Recently there was a lengthy discussion on the debian-security mailing list about the general security status and practises of php applications. There was, let's say, discomfort about exposed configurations, 'talking' files, etc... While drupal is relatively good in this respect, we should be able to enable better practises and offer advice on the site configuration choices. Not everyone is experienced. Some people are willing to learn.
This is why I mentioned the possibility of moving Drupal to the directory ABOVE the public_html, so nothing can be read at the web server level, and if the web server misbehaves, and does not process .php files, no peeping Toms can see the configuration. I have done this in the past on a crude CMS that was home grown. It needed changes to the php include path to work correctly, which we still can do in the .htaccess anyway, and guaranteed a certain level of security.