's better to export a collective hash (reference) or individual variables (as suggested by JavaFan)?

Personally, I wouldn't export either.

As I attempted to show above, I'd use individual package (our) variables, and use them via fully qualified references:

package MyConfig;

our $one = ...;
our $two = ...;
[download]

use MyConfig;

...
if( $x <= $MyConfig::one ) {
...
[download]

All the variable are nicely contained within the package stash (symbol table hash); warnings are issued for typos; and where they come from is clearly defined. And by not importing them, you avoid namespace clashes.

If they are truly constants, then I use constant and avail myself of the optimisations that brings.

Ah, I understand now. Many thanks :)

With your approach - declaring variables with "our" - would it lead to problems with mod_perl? I've never used mod_perl before, but I read that you can't have globals when using mod_perl.

Suppose I export the hashed variables (as in my approach), would that cause problems in a mod_perl environment?

Whether you can have, or cannot have, package variables is unrelated to whether the package variables are scalars or hashes, or whether they are exported or not.

Note also that if mod_perl means you cannot have globals, it would mean you cannot have Perl. Certain global variables always exist.

The issue with mod_perl is that modules get only compiled "once" (well, typically, once in the life time of an Apache child), and not each time the program is run. This means "globals" may not get (re)initialized. But that is not the same as package variables!. File scoped lexicals and sub-bounded state variables won't get (re)initialized either. And package variables that get initialized in your mod_perl program do get initialized.

The mod_perl issue all has to do when certain code is run - not whether variables are package variables or lexicals.