I would love that feature as well. I would have loved namespaces to be implemented that way, but it seems like nowdays those are most commonly used for autoloaders to find the scripts inside a folder structure (psr-4). 

I'd like to have "package" work similar to a namespace though, so it'll work easier across multiple files, but with visibility on classes. 

Example code:
-------------

<?php
package App\User;
namespace App\User\Some\Namespace;

// not available outside package "App\User"
private class UserRepository {
...
}

<?php
package App\User;
namespace App\User\Some\Other\Namespace;

use App\User\Some\Namespace\UserRepository;

// available outside package
public class UserFactory {
    private function getUserRepository(): UserRepository {
        return new UserRepository(); // works, because it's in the same package
    }
...
}

Expected result:
----------------
<?php
// no package, no namespace
// or different package
// or just namespace without package

use App\User\Some\Namespace\UserRepository;     // will cause error (private class)
use App\User\Some\Other\Namespace\UserFactory;  // works (public class)


It would allow developers to "hide" classes intended for use inside a part of a program (module, bundle or similar) only and enforce the use of design patterns like factories or facades for where it is deemed necessary. 
It would deny unintended uses of classes and reduce the possibility of unwanted dependencies.

Also, as a minor quality of life improvement, it would allow IDE developers to reduce the amount of possible classes shown after typing "new", which can be quite a lot in big projects, although only a few are actually intended to be used alongside "new", outside the 'package' they come from.

The problem is that PHP then has to check who is trying to access what at runtime. That's expensive.

This request is beyond the scope of what can be handled on this bug tracker. Anyone interested in this idea should check out the RFC process. https://wiki.php.net/rfc/howto