Which is what you asked for.

"Seems" is such a weasel word.  In this case, it means that you are resisting
the idiomatic Java way of doing things because you want your own internal
ideal language.  Java ain't that, so learn to live with Java's way.

It's not a real cost, it's one you made up.

My point is that there isn't any complexity or difficulty to the idiom.  It
only took about 15 minutes to work up that example.  Come on!  How hard is that?

To anyone used to reading Java, the code is hardly complex at all.  Just
because you think it looks hairy doesn't make Java's way bad.  Get used to
Java and it'll look a lot better to you.

It's a poor workman who blames his tools.

This was no "workaround".  The only difference between what Java does and what
you want is that Java makes the whole interface, say, package-private.  That
does exactly what you want, make the methods of that interface available only
to the package, with less code than if one had to mark every method.

It also keeps the self-documenting nature of 'interface' intact - that an
interface defines the public face to a type, the part others can see.  If
that's not what you mean to do, then an interface is the wrong thing to use.
Private, package-private and protected methods exist for the purpose of
implementation, yes, implementation, not contract, and therefore belong in a
class, for you, an abstract class, as was stated waaay upthread.

It would be silly and damaging to specify implementation in an interface.
It's against their very raison d'être.

My code points out how very easy it is - easy! - to contain the effects of an
interface to package level, using three different common Java idioms - a
top-level type declaration, a nested type declaration, and an anonymous inner
declaration.  All three idioms effortlessly contained their effects to package
level in a way that you call a "real cost", "restriction", and that you have
"not seen a corresponding benefit".

The cost is zero.  The benefit is that interfaces perform their architectural
role of specifying a contract, only, and that their effect can be contained to
arbitrary levels of protection so transparently that you misd-attribute the
complexity of an inner-class declaration to the lack of containment of the
interface.  The interface was so well contained that its contained nature was
invisible to you.  It really doesn't get any more effortless than that.

Unlike your approach, where one has to wonder method by method what the
containment level is.  Java's approach is much simpler, to the point where the
effort vanishes altogether.

I wonder if Sun could re-use the 'package' key-word to mean package
private.  This would allow new interfaces to explicitly declare a
package private methods.

interface SomeInterface {
  package someMethod();
}

To make things cleaner, I think I'd require public interfaces to have
only public methods, and 'package' interfaces to have only 'package'
methods. An interface with no 'package' modifier would default to the
current behavior.

interface PublicInterface [
  someMethod();  // Defaults to public, package not allowed.
}

package interface PackageInterface {
  anotherMethod();  // Defaults to package, public not allowed.
}