Subclassing to change configuration seems like a poor use of subclassing. You shouldn't create a subclass in order to change the data values in an object. If you later had some better reason to use inheritance you'd have to fit your inheritance into a existing tree of classes, which would likely be very complicated if you got it to work at all. Inheritance is best reserved more as a "last resort" in a design. The "is a" relationship is too inflexible and so should be invoked sparingly.

I hate Repeat::The::Really::Long::Class::Name->new() syntax. Package names should be very clear and globally unique and you should only ever mention them once in your code. I much prefer to have a (pre-configure) factory for constructing any objects:

my $Valid;
use Form::Validator(
    Factory=>\$Valid,
    AllowedTags=>[...],
    OtherConfig=>...,
    ...,
);

# ...

    my $obj= $Valid->new( ... );
[download]

That way you can use the same module two or more ways from the same code. You can store your pre-configured factory in a file-scope lexical, a package global, as a member of each object, anywhere you can store a lexical.

And, in practice, in Perl, it is often natural to just allow any object to be a factory for its own class. $obj->new( ... ) creates a new object using the configuration information from $obj. Then you may want a way to create a pre-configured but empty object to use just as a factory.