I've written exactly 2 programs with CGI (I do mostly other things with Perl than Web programming). I used CGI, because I know very little CGI, and Lincoln Stein seems to know a great deal of it. Most of what I post here is from typing <samp>perldoc CGI</samp>. I never read the source for CGI.pm.

Some answers:

How do i tell what was sent via 'get' and what was sent via 'post'?

See CGI's request_method method. There's even a section on "Mixing POST and URL parameters", if you really want to go that way.

What exactly is cgi.pm doing to the vars it slurps in?

This I couldn't understand, probably due to my lack of CGI experience. What vars is it "slurping in"? Script parameters? In other words, what would you like it to do, that it doesn't?

Accessing parameters in a hash

This is a true lack in CGI.pm, at least in the docs I have on a non-serving machine (2.46). (But a fix (using the param method, both without and with a parameter) should be easy to code.)See Corion's note on this topic; it's been addressed.

[I]f you have say, 'name=soemthing&name=blah', wont cgi.pm return an array for param('name')? What if your code doesnt want an array, what if you just want a nice little scalar value?

If you want a nice scalar value, you need to decide which of the possible scalar values you'd like to have. The param method returns different values in list context and in scalar context, so you could use "my $name = $q->param('name')". If, for some reason, you needed to get the middle value, you'd probably say something like

my @names = $q->param('name');
my $name = $names[$#names/2];
[download]

Think of it this way: if you want to use a list as a scalar, you need to decide how you want to do it; there is no "natural" way to do it. But you'd also need to make the same decision in your own code.

using your own solution may be less secure, but you can fix that!

True. But you're forgetting:

1. To fix it, you need to find it. If the bad guys find it first... In my case, I'd need to learn a lot about possible exploits against CGI scripts. CGI.pm might well contain security flaws, but Ariels_CGI.pm is guaranteed to contain them...
2. Laziness. Why should I chase down security flaws which have already been nailed down? What about new flaws? If there's a security flaw in Ariels_CGI.pm, I have to fix it. In CGI.pm, I stand a good chance of someone else fixing it for me.

HTML-generating methods

It's a free country (I hope). You don't have to use them if you don't want to. In one of my scripts, I didn't bother to use all of them, either.

However, regarding the difficulty finding unclosed brackets, a good editor and/or indenter (I use XEmacs) can give excellent feedback for Perl syntax errors; correcting nesting of HTML code embedded in Perl is harder.

Learning about CGI

Definitely an advantage to rolling your own. (If I had to write CGI in a language without the purty functions, I'd probably just wish I could use Perl...)</pp>

I'd mostly be worried about security. It's not so much about fixing the holes as about finding them in the first place.

But as you rightly note, TIMTOWTDI. As a programmer, it's your job also to evaluate the pros and cons of different approaches, and solve the problem the right way.