Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries

This could be an interesting idea on its own, but the goal of this RFC is a little different. Your problem your approach is solving is one part that I'm addressing, but I find the boundary enforcement at least as important. My argument is that it simplifies reasoning about internal dependencies, where you know that the only symbols that can be exported from a boundary module are those marked with pub(api), and the possible lint tooling can use the intended semantics to help out. The goal here was accomplishing that with the minimal syntactic and semantic changes to the language, which things like adding a vis top-level keyword would probably be too heavyweight for my purposes.

For your idea in particular, I'm curious if pub(<name>) is the best way of doing that, as in theory you should be able to use any visibility with that (not just pub). If you are already going to introduce the vis keyword for this purpose, maybe just using vis(<name>) would be better? Also, for the vis <name> = ... syntax, couldn't you just follow that with the visibility modifier itself?

Another question: what would the scoping be for the visibility name you define? If you define it in a submodule, would it only be defined in the modules below it? Would it only be valid at the crate root? Can visibilities be shadowed? Could visibilities have visibilities?