I tried a few different approaches, but to no avail. So instead, I'm going to post a variation on petral's that has the added advantage of actually working. I'm just being funny because I don't have anything better.

sub e{$a=$_;eval"\$a=~y/\Q$_\E/\0-¦/";$a}

sub c{
  ($_,$m,$n,$a,*d)=@_;
  map{$x=e;$_,[grep{e eq$x}@d]}
  /\b[^ ]{$n,$a}\b/g
}
[download]

Two quick fixes. Instead of using @$d, just use @d, but declare a glob in the parameter extraction phase, *d. A silly trick, I know, but I've got to use it while I can before Perl 6 comes and takes away all my toys. Second, for whatever reason, petral wanted to use the second parameter $m (the "alphabet") as the minimum, instead of $n. Thus, the range should be {$n,$a}, not {$m,$n}.

A change for the detail oriented required using '¦' (ASCII 127) instead of '~' (ASCII 126) in the pattern. It looks like the vertical pipe character, but isn't. The input specification said 7 bit (0-127), so this was a pseudo-off-by-one error.

Not sure how petral managed to get that thing working without noticing the parameter errors. Good show!

I'll just go on to post a few observations.

1. The tr// operator can be fed "garbage" input and still make sense of it. This allows you to do duplicate characters in the first part, such as "tr/froggy/abcdef" which when run on "froggy" will give you "abcddf" even though 'g' has two possibilities. The first is taken, subsequent ones are ignored.
2. You can always "overshoot" the second part of a tr by as much as you want. The extra stuff is ignored.
3. The \b characters do not match newlines or tabs when the [^ ] (not space) element is there to pick up the slack (greedy).