The short explanation is that Perl avoids endless loops by refusing to try to compile files that it is already compiling.

Here is how that rule plays out in this case.

1. Perl starts compiling test.pl.
2. Perl sees that it needs to use a, and so starts compiling a.pm.
3. Perl sees that it needs to use b, and so starts compiling b.pm.
4. Perl sees that it needs to use a, but we're already compiling a.pm so Perl avoids an endless loop by not trying to compile the rest of it right now.
5. Perl tries to run a->import, but there is no import defined for a, so Perl doesn't do anything. No output here, but you expected some.
6. Perl finishes compiling b.pm and runs b.pm.
7. Perl returns to a.pm and runs b->import, which runs. Output here.
8. Perl finishes compiling a.pm and runs a.pm.
9. Perl returns to test.pl and runs a->import, which runs. Output here.
10. Perl finishes compiling test.pl and runs test.pl.

To see that this is what is happening, change a.pm to the following:

package a;

sub import {
  print "import #1 in $_[0] called from ". (caller(1))[3] ." \n";
}

use b;

sub import {
  print "import #2 in $_[0] called from ". (caller(1))[3] ." \n";
}
[download]

This will change the output to:

import #1 in a called from b::BEGIN
import in b called from a::BEGIN
import #2 in a called from main::BEGIN
[download]

and you can see that b.pm really is calling a->import, but Perl has only compiled the file up to the use statement.

(General note. Circular dependencies tend to be poorly handled in many languages. If you can, you really want to avoid that. One strategy to handle the circularity is to explicitly require and import in the module that you want to see be loaded first. Another is to move critical code - such as imports - so they are executed before use statements.)