Well I would not be surprised on windows as file-paths in windows are case insensitive anyway.

If this is indeed an ActiveState issue, then this is a serious bug. I read up the perldoc for require and it does not indicate that the search be case insensitive. For example, try below:

File listing:

$ls -al
total 112
$ls -1
Interface
Parser
Parser.pm
filetest.pl
loadme.pl
[download]

Test code:

$cat filetest.pl 
#!/usr/local/ActivePerl-5.10/bin/perl
#===============================================
#
#         FILE:  filetest.pl
#
#        USAGE:  ./filetest.pl 
#
#  DESCRIPTION:  
#
#      OPTIONS:  ---
# REQUIREMENTS:  ---
#         BUGS:  ---
#        NOTES:  ---
#      VERSION:  1.0
#      CREATED:  10/12/2009 15:16:25 EDT
#     REVISION:  ---
#===============================================

use strict;
use warnings;


use FindBin qw($Bin);
my $good_filename = 'loadme.pl';
my $bad_filename = 'Loadme.pl';

print "Found $Bin/$good_filename" . "\n" if (-e $Bin . '/' . $good_fil
+ename);
print "Found $Bin/$bad_filename" . "\n" if (-e $Bin . '/' . $bad_filen
+ame);
[download]

Run results:

$./filetest.pl 
Found /Volumes/UserData/Users/dattanik/Programs/Perl/Work_area/Admin_s
+erver/lib/Admin_server/loadme.pl
Found /Volumes/UserData/Users/dattanik/Programs/Perl/Work_area/Admin_s
+erver/lib/Admin_server/Loadme.pl
[download]

...does not indicate that the search be case insensitive

No, but clearly indicated, in the equivalent code, is the fact that each module name is held as a key in %INC i.e. the underlying OS is responsible only for returning the/a requested file - thus only on a case-sensitive OS will require Foo; and require FoO; equate to different module implementation files being included i.e. on a case-insensitive OS, both require Foo; & require FoO; equate to the same module implementation file being included.

A user level that continues to overstate my experience :-))