Well, you cannot access any member from different package...

It depends. When the package-private class implements a public interface, then the corresponding public members 
constitute a public API in a very real sense. Furthermore, and this is my actual concern, when choosing to make a class 
package-private, because it is only used within the respective package, one usually still defines its API as if it 
where a public class, that is one distinguishes properly between public and private members (and possibly protected 
ones).

I'd like to use the Navigator to see at a glance what the public API of a class is (as opposed to implementation 
details), even if the API happens to be accessible only to others classes of the same package. Even between classes of 
the same package, there is a distinction between hidden implementation details of a class and its actual API towards 
the other classes. It's still as much an API as with public classes.

This issue is about personal preference. If I turn off "show non-public members" I expect, that I will see only public
members. And package private class is really not public. I understand your use case, but we cannot do both things.
Changing to enhancement.

Hmm. In my opinion this isn't just personal preference. The members are declared with the 'public' keyword, and they 
*are* public relative to the class (= published/exported by the class), even if the class is not public relative to the 
package (= not published/exported by the package). These are two different scopes. And the Navigator is about the class 
level, not about the package level. (I know how the Java Reflection API behaves, which is probably the reason for the 
current state, but that's beside the point.) The flag is currently simply useless for non-public classes, because there 
it basically just means "(don't) show anything". Not even public members inherited from public classes are shown.