I cant come up with a good example right now, but there are definitely times where i'd want false (but defined) to indicate a behavior different than for undef.

Likely, shemp was thinking along the lines of an optional numeric option. A crazy example I can think, goes along the lines of "how many errors will this parser tolerate before throwing an exception".

You could leave the option undef to mean "no amount of errors will make me throw an exception", zero (also false) to mean "allow no errors at all" and a positive value (true) to mean "allow for up to this many errors".

However, the most common usage is to have undef stand for "not specified/wanted" and a true value for the contrary.

Maybe I'm not understanding what's being said here, but is shemp arguing for my style? It seems only if you have undefined clearly distinct from false and you explicitly test for it that you can really benefit from "false (but defined) to indicate a behavior different than for undef".

One cool possibility that I thought of last night that is made possible by my style is this: If the script has some debug level parameter passed in (or built-in perhaps), the script would report to you informationally when you are setting a parameter to its default value. This might be helpful information to the user and it would not be possible if you set the default value before calling GetOptions.

Yes, actually, i am saying that there are cases where this is useful. One i just thought of that doesnt actually apply to input, but rather to return values is the built-in wantarray(). The return values are as follows

undef if the sub was called in void context
defined but false if the sub was called in scalar context
true is the sub was called in list context.