Usually, when you need to instantiate objects, but the objects could be of several different classes based on what the user needs, you can use the Builder pattern. When building the builder object, you pass it all the arguments common to all the constructors of the different classes it can instantiate, it can then have several builder methods, one for each class, which take the arguments specific for the class's constructor.

If some of the methods have the same implementation in multiple classes, create an abstract parent class from which all the classes inherit (Foo::Common below), or use roles to implement the methods (not shown in the example below).

OO classes don't usually export anything. To import constants, use a dedicated class.

For a small project, this might seem like a Java-level verbosity. For larger projects, one would get mad at handling the different flags and ternaries in method implementations; with the Builder pattern you always know where to look when you need to see the implementation of a particular behaviour - and if it's not in the file, it tells you where to look further (parent or role).

I've used this at a $job - 2 with tens of constructor parameters, built on Moose. It worked great.

Thank you very much for detailed answer, I appreciate. Never seen __PACKAGE__ for "true" at the end of module, learning something new each day.

Constants go to dedicated module and "modern" user is told to "use" it. Gratefully accepted.

To answer your other comment: yes, the OOP, shared code/behaviour and separate data/properties, I have some vague idea. If "import" redefines the subroutines, it's once and for all. Though I didn't expect such mixed usage scenario, I planned to eventually do at least something about it, like (assuming $MODE undefined initially):

sub import {
    my ( $self, $flag ) = @_;
    
    if ( defined $flag and $flag eq ':modern' ) {
        if ( defined $MODE ) {
            if ( $MODE == 0 ) {
                warn "Note: Foo is in classic mode\n"
            }
        }
        else {
            $MODE = 1;
            Foo-> export_to_level( 1, 'Foo', keys %const );
            
            no warnings 'redefine'; 
            *Foo::m2 = \&Foo::Modern::m2;
            # etc.
            # longer list
        }
    }
    else {
        if ( defined $MODE ) {
            if ( $MODE == 1 ) {
                warn "Note: Foo is in modern mode\n"
            }
        }
        else {
            $MODE = 0
        }
    }
}
[download]

If someone does just (or mixes with other uses) "require Foo;" or "use Foo();" it'll be considered an act of direct sabotage ;-) But in the end I'll probably abandon the idea to abuse "import", therefore doesn't matter. I don't understand, however, what's the benefit of "Builder". The "script.pl" is written by the end user, all she wants is simply "use Foo;". If asked instead from this day on to:

use Foo::Builder;
my $builder = 'Foo::Builder'->new;
my $object = $builder->build('classic');
[download]

then I'm afraid to be pointed at the door. Or if in less grumpy mood/mode, she'll agree to hit a few more keys to "use Foo::Classic;". And if "modern" user happens nearby, he'll say "Aha, I'll do use Foo::Modern; use Foo::Constants; then!"

I was hoping to use a single ternary to check a flag in, say, 60 lines method (and there are several such methods) so that 2 of these lines are executed in this or that mode; instead of keeping almost exact duplicates in two packages. I'll think more about it and ask further. Thank you.

Personally would have created 2 wholly separate versions. And soon after would have picked one to continue to maintain & develop.