...

Hmmm...  I don't think I consider the visibility of a method part of
its implementation -- any more than say its return type.

Regardless, I don't think the visibility of the interface makes much
practical difference if the interface is only implemented in package
level code.

E.g., let's consider that we've adopted your rule and package visible
interfaces are implemented only in package visible classes.  Clearly
the interface is not visible to the public, nor can any implementation
of any method in the interface be accessed outside the package.

Now let's make the interface public.  We still want to restrict use
the interface to one package, but we're exploring what making it
public does. So what happens?

The clearest change is that external(to the package) users can now
access the constants defined in the interface.  That's a real change
and its certainly useful to restrict visibility of constants in some
cases, but our dicussion heretofore has focussed on how methods are
affected.  What happens there?

Public users still cannot directly access the implementation of any of
the methods, because the class protections for each of the
implementing classes are still set to package level.

Ah, but they can now create their own implementation of the interface
and pass it in to some public method that takes the interface as an
input and thus get access to something they weren't able to get to
before...   I.e.,

   package pack;
   public class SomeClass {
       public void someMethod(HiddenInterface x) {...}
   }
   ...
   package otherpack;
   public class NewClass implements HiddenInterface {
        void crackingMethod() {
             someMethod(this);
        }
   }

where HiddenInterface is the interface that we just made public.

Here crackingMethod is able to inject an instance of the new user
class and clearly might have access where it didn't before.  So this
seems new...

That's right, but why was there a public method in a public class that
used a type that didn't wasn't supposed to be available to the
public?  The only legitimate reason I might see is that  'someMethod'
is itself defined in an interface so it needed to be public.   But if
it's in an interface that uses HiddenInterface, then presumably this
second interface is also only supposed to be used within the package
so by hypothesis we shouldn't be implementing it in a public class.

So what did the package level protection get us:  It hid constants and
it's probably useful as a bit of documentation:  it can indicate we
should limit visibility of certain classes and methods, but at best it
should act as kind of backup, cleaning up if we make errors in some of
our visibility specifications for methods in public classes.

That said, I'm not sure I agree with your first statement above...
Users should feel free to implement package level interfaces in public
classes.  There may be many cases where that's fine.  All I've ever
said is that if they do so, they need to recognize that the
implementation of the methods  of the interface must be visible to the
public regardless of the visibility of the interface itself.

I can see reasonable cases for any combination of public and package
classes implementing public and package interfaces, but the
interactions of the visibilities of the classes, interfaces and
methods are rather subtle.
And all this is before we consider how inheritance might affect all of
this!

  Regards,
  Tom McGlynn