I've some experience on this matter from both sides of the fence as a mod_perl programmer and inside experience with a hosting company.

My experiences as a mod_perl programmer would lead me to believe that the users running mod_perl on Apache have to trust each other. End of story. This pretty much rules out mod_perl hosting IMHO.

You could run multiple apaches on multiple IP addresses but this means your server is going to need a lot of RAM and some trust of the users. Our e-commerce server (mod_perl/Apache) frequently has 50 Mb mod_perl processes - this just isn't going to be acceptable to an ISP.

I think the only way you'd get this to work is to run virtual processors using vmware or IBM's linux on a mainframe. This would then hard limit the resources each subserver could use and make sure there was no interaction between users. You could probably only run a few dozen per server though making it a premium service.

I hate to admit this but PHP is a lot easier from the ISP's point of view. In fact it is easier to manage than CGI which can easily cause a server to get out of control if you aren't careful.

I wish there was a half way house for mod_perl which wasn't so embedded into the web server but still had the advantages of persistent processes. There is always FastCGI I suppost...

My conclusion is that if you want to run mod_perl you'll have to get your own server (or club together with some friends).