I don't think we would ever want changing an import statement in one file to impact how other files are type-checked, so that's enough to cross that possible interpretation of <access-level> import off the list in my mind. While it's possible it might be confusing to some users at first, my own opinion is that I think we'd be hard-pressed to find a more concise and clean spelling of the concept being pitched, nor do I think the feature would be improved by trying to come up with something more verbose here.
open isn't just an access level above public; it has a specific meaning around subclassing of types, so I don't think it would be appropriate to use it to support what @_exported currently does. Module A writing @_exported import B really means "when A is imported, B can also be used as if it was imported at the same location", and that's a very specific concept that doesn't map to the access level-based approach being proposed here. If <access-level> import X means "the names in module X can be used by <access-level> or lower declarations in the importing file", then it would be very confusing if open import did something completely different than that.