I'm not sure what you mean.  { row => ["row", "row", "row", "your boat"]  } looks like the "right" answer to me... What were you expecting?

That line is generated by the workaround

This is Vars output

  { "row[]" => "row\0row\0row\0your boat" },
[download]

And this is what your module does with vars output

 { row => ["row\0row\0row\0your boat"] },
[download]

This is the bug, it forgot to split on \0, because Vars joins on \0

or better still it should simply accept a CGI.pm compatible object (one with param method, whether its CGI/CGI::Simple/CGI::Lite.....) and use the Vars workaround on it

Do you get it now?

That line is generated by the workaround

[...]

This is the bug, it forgot to split on \0, because Vars joins on \0

Oh, I see what you mean. Hm. I hate that NUL stuff...

I guess the best thing would be to add a config'able (probably on by default) splitting on them to the processing. I like that better than expecting a ->param, since that breaks it away from the contract of purely hash->hash.

I'll see if I can't get that into a new release in the next few weeks. Annoyingly busy... :|

I like that better than expecting a ->param, since that breaks it away from the contract of purely hash->hash.

Adding a branch breaks no contracts

sub build_cgi_struct
{
    my ($iv, $errs, $conf) = @_;
    
    use Scalar::Util qw(blessed);
    my $blessed = blessed $iv;
    my $splitnull = 1;
    if( $blessed and UNIVERSAL::can( $iv, 'param') ){
        $splitnull = 0;
        if( $iv->isa('CGI') ){
            $iv = $iv->{"param"} ; # cheat :)
        } else {
            $iv =  { map { $_ => [ $iv->param($_) ] } $iv->param  };
        }
    }
    ...
    ... if $splitnull;
[download]

I'll see if I can't get that into a new release in the next few weeks.

Well, OK, it's still just a few weeks. FSVO "few" :)

I've uploaded a new version that does nullsplits by default (as well as one or two other minor tweaks).