Fwd: Intended proposal for class visibility

Hey there!
I'm thrilled since this is my first proposal.

I'd like to propose a new visibility schema for classes, based on a explicit
group of namespaces allowed to use the class.
The goal of this proposal is to provide a way to cover from a native
language feature what currently is usually patched using "@internal"
annotations.
If the visibility declaration ("internals" in this example) is present, the
class could only be visible for other classes on the list of the specified
namespaces.

<?php

namespace Vendor\Library\Feature;

final class Foo implements Vendor\Library\InternalInterface internals
Vendor\Library, Partner\VendorBridge
{
}

/// this class will be allowed to use Vendor\Library\Feature\Foo because
it is declared directly at Vendor\Library namespace

<?php

namespace Vendor\Library;

use Vendor\Library\Feature\Foo;

class Allowed
{
public function __construct()
{
new Foo();
}
}

/// this class will be allowed to use Vendor\Library\Feature\Foo because
it one level under Vendor\Library namespace

<?php

namespace Vendor\Library\Service;

use Vendor\Library\Feature\Foo;

class Allowed
{
public function __construct()
{
new Foo();
}
}

/// this class will NOT be allowed to use Vendor\Library\Feature\Foo,
since the current namespace Vendor doesn't match and is not under
Vendor\Library nor Partner\VendorBridge.

<?php

namespace Vendor;

use Vendor\Library\Feature\Foo;

class Disallowed
{
public function __construct()
{
new Foo();
}
}

I think a good example of the kind of project that can leverage this
feature are the libraries which expose a public API with its own
implementation, but need to protect their internal classes in order to
avoid them to be tied to their BC promise.
Note that I really don't know how to implement this internally, or if this
must be just related to the autoload mechanism instead of a (maybe) more
complex compilation phase.

Please, let me know if you have some concerns or doubts about it.
Thank you in advance.

--
Javier Spagnoletti