Even so if you change lib=s to lib=f and then use the following command it still does not complain (and error out since lib should be a float)

It's not an error because of pass_through. It causes anything wrong to left in @ARGV for further processing. For example,

use Getopt::Long (); 

our $opt_float;

Getopt::Long::Configure('no_auto_abbrev','pass_through');
Getopt::Long::GetOptions('float=f')
   or die("Bad args\n");

print("\$opt_float = ", defined($opt_float) ? $opt_float : "[undef]", 
+"\n");
print("\@ARGV      = ", join(' ', @ARGV), "\n");
[download]

returns

>perl 551380.pl -float 1.3
$opt_float = 1.3
@ARGV      =

>perl 551380.pl -float abc
$opt_float = [undef]
@ARGV      = -float abc
[download]

I'm not arguing with your explanation of how things are working w/ pass_through. I'm asking if was anything in the settings to make it work differently. The problem in the second example you showed is that if I have in the code constructs to set $opt_float to a value to if it is undefined then I have unintended program execution despite the fact that there is a user command line type error. It requires me to parse ARGV to check against such a scenario. Again, sorry for accidently starting two separate sub-threads on this topic. Thanks for you help.

I'm asking if was anything in the settings to make it work differently.

Yes. If you don't want pass_through's behaviour, don't use pass_through.

use Getopt::Long (); 

our $opt_float;

Getopt::Long::Configure('no_auto_abbrev');
Getopt::Long::GetOptions('float=f')
   or die("Bad args\n");

print("\$opt_float = ", defined($opt_float) ? $opt_float : "[undef]", 
+"\n");
print("\@ARGV      = ", join(' ', @ARGV), "\n");
[download]

outputs

>perl 551404.pl -float 1.3
$opt_float = 1.3
@ARGV      =

>perl 551404.pl -float abc
Value "abc" invalid for option float (real number expected)
Bad args
[download]