Let's see if you find this thread again
So. The problem is really, even if "most" blogs/cmses do not rely on DOCUMENT_ROOT, still this special directive is really important to s9y, much more important if a s9y installation already exists in the "lower" directory.
As I wrote earlier to Grischa, we could try to employ various fixes, but this would mean we'd have to test every other edge scenario again, and setup (complicated) setups to test this with, all of which is a massive body of work.
Technically it's also not very good, that the Ubernauten do this kind of trick. I mean, the document root of a VHost is the root of where all documents start, and not where the user himself has his home directory. Relying on that this will work on most PHP applications is a very optimistic approach, that will very likely break not only on Serendipity.
IMHO it would be nice to get into a discussion on how the Ubernauten and other Webproviders can find a way to delegate the technically correct document root to a subdomain, without losing their suexec specific setup. I am not an expert webhoster, so there definitely might be problems with this, but as an application developer supporting different scenarios, I have a problem with setups where the document-root is not what it's intention actually would imply.
A suggestion I made before was to create a .htaccess file to set a php "auto_prepend_file" that points to a PHP file which sets $_SERVER['DOCUMENT_ROOT'] to the proper directory.
If there is a way in PHP code with which we can EXACTLY identify a Ubernauten-Setup (or any of this redirected subdomain document root), I can put this into the s9y code; but this can not have side-effects on other installations, so this "ubernauten"-Check needs to be foolproof, best due to some $_ENV setting.