Since a lot of the discussion is revolving around whether we should consider solving these problems with @_spi instead, I'd like to elaborate on one of my posts from the pitch thread:
It is an important goal for me and many others in this discussion that the second and third rows be addressed distinctly. For package implementers there's an important advantage to being confident that you are free to evolve package visibility declarations as needed, without having to worry about outside dependencies you have little control over. When refactoring code in a package, encountering the package access modifier should give you a warm fuzzy feeling: "phew, this declaration is probably not going to be a straight jacket that limits my ability to make necessary changes." Encountering declarations with @_spi, on the other hand, yields a different kind of reaction: "Darn, I'm going to need to do research to figure out how complicated it is to change this and who I need to coordinate with in order to do so."
Folks have rightfully pointed out that we could design an official version of @_spi that is a tool for both jobs either by teaching the tooling which SPI groups are package private or by adding extra arguments to the attribute. I do understand the sentiment that these concepts are close enough to each other that maybe we could get a two-for-one by designing a shared solution, but I haven't seen an argument that convinces me that combining them is a superior design for the specific need addressed by package. One thing in particular that bothers me about reusing the @_spi approach is that I think the ceremony of declaring named groupings does not pull its weight for package private declarations because most of the time you're just going to declare one name for them. I think that if you address all the problems with reusing @_spi (tooling needs to be aware what's package private, group names are superfluous, naming @_spi at the import declaration is questionable ceremony for this purpose) then you wind up back where we started with a different spelling of the same thing that is being proposed.
I'm coming around to this perspective. Although it's a mouthful I do wonder if we should name this access level something like packageprivate since a package declaration does look like it is declaring an object which is a package.