From @raydiak

See attached. I've only tested this on JVM. When run with -Iblib, dispatch fails. When run with -Ilib, it appears to work correctly, but the stack trace shows A being called from B...don't know if thats expected behavior, but it surprised me enough to mention it.

From @raydiak

precomp_export_fail.tar.gz

From @FROGGS

Can you put that code in a repo or gist? I can't open the tarball...

The RT System itself - Status changed from 'new' to 'open'

From @raydiak

https://github.com/raydiak/precomp-export-fail

From @FROGGS

perl6-m seems to reveal it a bit​:

I can explain this​:
$ perl6-m -Ilib test.p6
everything seems to be working correctly
  in sub foo at /home/froggs/dev/RT#​121319/lib/A.pm6​:6
  in sub foo at /home/froggs/dev/RT#​121319/lib/B.pm6​:3
  in block at test.p6​:5
You use A which uses B, which declares the multi foo. At that time the proto is generated, and later in A the multi foo is added to that proto. So the dispatch happens in the proto of B.pm.

Now we know that different compilation units are in charge to give the full list of candidates, but something happens so that the candidate of A is not added to the proto of B​:
$ perl6-m -Iblib test.p6
Cannot call 'foo'; none of these signatures match​:
:(B $foo)
  in sub foo at lib/B.pm6​:3
  in block at test.p6​:5

From @FROGGS

The candidate in A is added to the proto as long as we compile A.pm, but after deserializing A we only have the proto of B.

You can prove that by added "BEGIN say &foo.candidates;" before and after the multi declaration as well as in the test.p6 after the use statement.