Opened an issue as suggested, including the strange behaviour as discovered by choroba

Interestingly, the search for a suitable workaround resulted in a remarkable boost for my specific application. Here the sets represent indices from another piddle and one operand is taken from a piddle holding several sets, which requires equal dimensions for all sets. This is achieved by padding the sets with BAD values at the end. With a small modification, the values can be placed just at the position they represent and the remaining values set to BAD. Then an intersection may be performed almost with a simple dice.

E.g.

my $data = pdl ...; # 1-d
#my $set1 = $data->where(something); # before Update 1
#my $set1 = $data->which(something); # before Update 2
my $set1 = which($mask1); # $mask1 having the shape of $data
my $full1 = zeroes(indx, $data->dim(0))->setvaltobad(0);
$full1->dice($set1) .= $set1;
#my $set2 = $data->where(other); # before Update 1
#my $set2 = $data->which(other); # before Update 2
my $set2 = which($mask2); # $mask2 having the shape of $data

# Now the intersection of $set1 and $set2 is:
my $tmp = $full1->dice($set2)->sever;
my $intersect = $tmp->where(isgood $tmp);
[download]

The result in $intersect can be found much faster with dice than with setops for a large sized $data. An older issue with setops revealed the usage of uniq within setops, which sorts the data making it O(N log N), while the dice approch should be O(N). In my application there is no overhead in constructing $full1.

Probably this is already described somewhere else.

Update 1:
It must be $data->which(...) instead of $data->where(...). Modified the example.

Update 2:
The example was still faulty. The key for this to work is $set1 and $set2 being piddles holding indices from $data as said in the paragraph above. Modified the example once again. Regard it as pseudocode.