Speaking of the solution in two steps, it can be written like this:

$count = unpack "C", $str;
@values = unpack "x C$count (V$count)2"
[download]

my table driven decoder is just too dumb to do it in two steps...

I suppose you can't change the way the data is packed either? Because if you pack only V values, you just have: my (@values) = unpack "C/(V3)", $str;

I wrote a decoder that reads binary telegrams (or messages) with different types (meaning different structures) from a log file. For each telegram type the table has an unpack template that defines the structure of the telegram and a list of names for its fields. The structure is unpacked and the values are formatted with their names to make a readable string representation describing the content of the telegrams.
Currently this works well with simple types and single arrays prefixed with their length. The structure of the telegrams are given and part of an interface. I agree, there could be simpler unified packings, but that is what I have to deal with.
Maybe it is a good idea to allow 'two step unpacking', in order to enable the decoding of more complex structures. Thanks, I have to think about it.

G'day hexcoder,

Perhaps, instead of a table of just templates, you could use a table of coderefs whose functionality includes preprocessing, unpacking, formatting, and anything else you need.

Here's a highly contrived and primitive example just to show the technique.

#!/usr/bin/env perl -l

use strict;
use warnings;

my %decode_type = (
    A => sub { "Do TypeA stuff with '$_[0]'" },
    B => sub { "Do TypeB stuff with '$_[0]'" },
);

while (<DATA>) {
    chomp;
    my ($type, $msg) = split /\s+/, $_, 2;
    my $decoded = $decode_type{$type}->($msg);
    print $decoded;
}

__DATA__
B message B1
A more complex message A1
B message B2
[download]

Output:

Do TypeB stuff with 'message B1'
Do TypeA stuff with 'more complex message A1'
Do TypeB stuff with 'message B2'
[download]

I don't know how useful that might be; however, your general description suggested this approach.

— Ken