Should protection attributes disambiguate?

[so]

On Tue, 21 Jun 2011 06:04:28 +0300, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> It matters for stuff like NVI (Non-Virtual Inheritance). In that  
> particular
> case, you overload a private function but you can't call it. You couldn't
> overload it if you couldn't see it. So, there _are_ cases where it  
> matters,
> and it _is_ an important distinction. It's just that it matters  
> infrequently
> enough that most people don't realize that there is such a distinction.  
> But
> distinction or not, I don't see why we couldn't just make it so that any
> attempt to use a symbol where the clashing symbol can't be used anyway  
> just
> doesn't clash by ignoring the private symbol in such cases.
>
> - Jonathan M Davis

Good example, is it only this or are there any others?
I am asking because i think this particular use case doesn't justify  
visibility but not access.
If i got it right, we are talking about something like this:

module base1;
private import base;
struct base1 : base {
}

module base2;
import base1;
struct base2 : base1 {
}

Shouldn't compiler just issue an error whenever base1 accessed outside of  
the module it belongs?
With its current state, it just encourages bad design as far as i can see.  
First of all inheriting from a class/interface/struct that is imported  
private implies this new class is going to be an implementation detail,  
hidden from user. If it wasn't intended, why would you import it private?