Inheritance and access control - "private protected"

Question

I'm reopening an old topic, seems to have been last discussed here 2-3 years ago.
It concerns the concept of restricting access to class members to itself, and its subclasses. This is what "protected" does in C++ and "private protected" did in early versions of the Java language. This feature was removed from Java with a motivation along the lines of not being "simple", and "linear" (in line with the other access modes, each being a true subset of the next). Unfortunately, the article which explained Sun's position on this keyword combination seems to have been removed from the site, so I haven't been able to read its original text.
But regardless of simplicity of implementation or explaining Java's access modifiers to newbies, I believe it is a fundamental part of OO programming for such an access mode to exist. The arguments for having the standard "private" mode in fact also apply for having a C++-style "protected" mode. (Arguing that classes within a package are related and it therefore doesn't hurt to also give them access to Java's "protected" members, is equally arguing that "private" is unneccessary, which noone of course believes.)
The whole concept of inheritance and polymorphism and encapsulation builds on the access modes private, protected, and public (in the C++ senses). In Java the "package" concept was added - a nice feature! But I see no justification for it to negate the proper encapsulation of a class and its specializations.

Answer 1

What effect upon inheritance other than hiding members
from subclasses is there?
None. And I cant think of another declaration that prevents members from being inherited but private.
Of course the onus comes on the programmer with Java's
definition of "protected" - but
1) there is rarely a single programmer working within
a package
The point was the package is a unit which does not hide from itself. Just like all methods within a class can see each other, all classes within a package can, and all packages within a program can.
2) it muddies the encapsulation in the design - when
you see a "protected" method someone else, or yourself
some time ago - wrote, how do you know if the design
intention is to have it accessed solely by the class
and its subclasses, or if it is indeed intended to be
shared with the whole package? The only way to do
this today is to always explicitly specify this in the
comments, which may be lacking, inconsistent, and
abused (since it isn't enforced).Encapsulation would be implementation hiding. Not method hiding. The only thing you should probably allow out of your package is an interface and a factory anyway.
I understand where you are coming from, but I really have not had occasion to take issue with it. I can't think of a real codeing situation where this is required. OTOH, I can't think of a coding situation where I need to access a protected method from another class either.