The reported behavior actually does conform to the words of the quoted specification: the interface p1.Outer.Inner is public, because it is a member of interface p1.Outer, and all members of an interface are implicitly public (see JLS3 9.1.5); therefore, there is no requirement that the generated proxy class be in the same package (p1).
The point could be taken, however, that the words of the specification do not match their more abstract original intent, which was for the "right thing" to implicitly occur regarding the implicit choice of package for a dynamic proxy class, given the accessibility of its proxy interfaces, so that IllegalAccessErrors should not occur.
The Description of this bug report is not too specific about the negative ramifications of this behavior, other than mentioning IllegalAccessError (it's not demonstrated by the test case), but I think that I can guess the cause. There is a general flaw with the specified algorithm for implicitly choosing the package for a dynamic proxy class based on the accessibility of its interfaces: even if a proxy interface is accessible to all code, implementing it still may require the proxy class to reference types that are not accessible to all code-- specifically, the return types of all of the interface's member methods (which the proxy class's implementations must cast the results of InvocationHandler.invoke invocations to) and certain of the declared exception types of the interface's member methods. If one of these types is not generally accessible, then the generated proxy class will cause an IllegalAccessError if it is not in the same package as that type (note that the type is not necessarily even in the same package as the proxy interface, if the associated method is inherited, not declared, by the proxy interface).
I am disinclined to think that the specification should be amended so that the "right" package is implicitly chosen in consideration of the full generality of the issue described in the previous paragraph-- it would require adding quite complex rules for arguably academic cases. It doesn't seem useful for a public interface to depend on non-public types. In previous cases that I am aware of in which people have encountered this issue, they generally agreed that the interface being public was a mistake, and thus the problem was "worked around" by correcting that mistake.
The particular reported case, however, seems a little more special, because A) interface member interfaces are inevitably public and B) a normal class in an arbitrary package could not implement p1.Outer.Inner, because it would not be accessible (JLS3 8.1.5, 6.6.1). It seems that the original intent of the specification regarding the implicit package choice would have been better met if it were conditioned on the interface not being accessible to code in all packages, rather than the interface being non-public. The more general flaw described above would still exist, but for the reported case, the dynamic proxy class would then be created in the expected package, p1. So, the specification and implementation could be fixed to allow this. It's not yet clear to me how important this case is in practice, however.