A short guide to adding tests is in order, because if you report a bug, the standard reply will be "write a test for it".

There's currently a bug in Pugs that makes array references flatten in list context. A bug test is simple: write what you did and what you expected first:

# What I did
my @foo;
push @foo, [];

# What I expected
@foo.elems == 1
# But I got @foo.elems == 0
[download]

Then, rewrite the expectation as a test:

ok(@foo.elems == 1, "\@foo has 1 element");
[download]

If you're dealing with comparison, it's better to use is() instead of ok(), because you then get extra debugging output:

is(@foo.elems, 1, "\@foo has 1 element");
[download]

Add enough stuff to make it a script (the "plan" is the number of tests in the test script), and make sure you're loading the Test module:

#!/usr/bin/pugs

use v6;
use Test;

plan 1;

my @foo;
push @foo, [];

is(@foo.elems, 1, "\@foo has 1 element");
[download]

And then report your bug-report-test to a pugs developer, so that it can be included in the test suite. It'll remain there for a long time, to make sure that the bug, once fixed, won't come back (regress).

If you have write access in the repository, commit the test as pugs/t/pugsbugs/foo.t, where foo is descriptive (in this case, the test is in flattening.t). If you will be reporting multiple bugs, request committer access from Autrijus. Giving you access once is easier than copying and pasting every bug report test.