Using IN runs the risk of stomping on a globally-defined IN from somewhere else (eg. the calling program).

Only if the calling program does something stupid like:

open( Gstat::IN, ...
[download]

I particularly like your use of pod, intermixed with the code in such a way that each subroutine is documented by the corresponding pod block.

While that works for strictly linear reading of code, the lack of visual distictiveness of POD (especially when POD includes code snippets, which most good POD does) make that style problematic for many other styles of reading code. It isn't all that bad in this particular case but that is mostly due to the fact that the pod for most of the functions is nearly minimal. When the documentation becomes more extensive (which usually happens with good modules), it will become quite painful to find the code amid the POD, at least for people like me who usually read code more holistically than strictly linearly. I also find that it interferes with updating and especially organizing the POD.

Why not use the 3-argument form of open?

Or, if you don't want to make your code not work for people who for some reason may be stuck with an old version of Perl, at least be specific about the fact that you want to read the files (which provides the most important benefits of 3-argument open):

open( EXP, "< $expFile"­ )
[download]

Not that I disagree with any of your suggestions (just with your encouragement of intermixing POD and code).