I don't know a lot about mod_perl so I did not have that in mind. Parallelism can be an issue when modifying package vars in different threads (as with anything else). But as there are different ways to import a module (e.g. use, require but especially do (and eval) which asker uses a lot) and there are also ways to reload a module at runtime (e.g. Module::Refresh) I thought it's better to leave a questionmark there rather than being absolute. Given also that there are other safer ways to achieve read-write effect. Personally I can't stand things like: $DBI::errstr, whereas $XYZ::DEBUG = 1 is tolerable.

What's your opinion? Can we rely on the state of a package's variables modified after loaded (not in mod_perl, threads)?

My opinion? Writable global variables are bad. Having a writer is much better as you can intercept it, which allows to debug it, wrap it, log it, etc. Global constants are basically OK, but it's still suspicious if a certain value is needed in several different places - maybe they should be moved closer together?

The situation in mod_perl like environment is easy to demonstrate. But let's be more modern, it applies to plack as well, for example:

#!/usr/bin/perl
use warnings;
use strict;

use Plack::Builder;

our $global = 1;

my $app = sub {
    my $env = shift;
    my $status = 200;
    my $headers = ['Content-type' => 'text/html'];

    return [$status, $headers, [$global++]]
};

builder {
    mount '/' => $app;
};
[download]

Now run it as (sorry for *nix shell, but that's what I run)

plackup -s Starman --workers 2 11130232.pl
[download]

Now run several requests in parallel, e.g.

for i in {1..100} ; do curl http://localhost:5000 & done
[download]

and check what the global state is several times:

$ curl [HTTP://localhost:5000]
55
$ curl [HTTP://localhost:5000]
47
[download]

Each worker keeps its own state, but you never know which one you'll hit.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]