I'm not sure why everyone is so against your proposal. I'm not a big fan of "do file", but this is one of the best uses of it I've seen recently. A better way of doing the same thing is:

if ($Action eq 'foo') {
    require 'foo.pl';
    &foo();
}
elsif ($Action eq 'bar') {
    require 'bar.pl';
    &bar();
}
else {
    require 'baz.pl';
    &baz();
}
[download]

but both versions boil down to the same thing if that code will never get executed more than once in the same run. (If that code gets executed more than once then the do version can compile the external code more than once which will be slower and probably give you warnings.)

And both versions will save the CPU time and memory required to compile two sets of subroutines. If the sets of subroutines are fairly large, then that could be quite a savings (for a short-running script like a CGI is likely to be).

Something like this even has some advantages over any implementations of autoloading that I have seen. For example, using the debugger on this code will be a fairly normal task while using the debugger on autoloaded code usually doesn't work very well (you can make it work quite well, but I haven't seen any implementations that bother to do that). For same reason, autoloaded code that reports source code line numbers says things like "at (eval 14) line 5", which isn't helpful.

With the require approach, you can put something like:

if(  $ENV{DEBUG}  ) {
    require 'foo.pl';
    require 'bar.pl';
    require 'baz.pl';
}
[download]

at the top of your script and have errors reported sooner rather than later during testing.

Finally, please don't use &foo;. See (tye)Re: A question of style for more on that.

        - tye (but my friends call me "Tye")