That may mean Zaxo had a different application in mind (where each variable had different constraints, and the need to define a factory function would have just made the module harder to use) . . .

You're exactly right about that. The original idea was just a bit of implementation to demonstrate validation for lvalue closures. My initial real application was to retrofit validation and detainting to cgi form processing scripts. No commonality was assumed for the variable types. It was later that I noticed more general applications for the module.

The idea of a factory-like method for constraining lists of variables is a good one. I'll add it to the TODO list. Here's an untested first cut at it:

use Tie::Constrained;
sub Tie::Constrained::tiethese {
    my $self = shift;
    map {tie $_, 'Tie::Constrained', $self} @_;
}

my $integer = Tie::Constrained->new(
    sub { $_[0] =~ /^[+-]?\d+$/; }
);

my ($i,$j,$k,$l);
$integer->tiethese($i,$j,$k,$l);
[download]

As diotalevi said, functions return lists of values, not variables, so a method to tie a bunch of variables pretty much needs to be handed the variables and work with their aliases. You may not have noticed the constructor for unbound Tie::Constrained objects. I put that in to take the anonymity out of the subtypes and allow more readable ties with often-used constraints.