This already exists in Swift today, because the same case could be made for any fileprivate or private declaration at file scope. Unfortunately, I think that ship has sailed and having the inconsistency for imports would put us in a worse state than allowing the redundancy.
This concern was raised in the pitch thread as well, but to reiterate what I said there, I don't think there's a world where it's desirable to have imports from one file affect type checking in other files in the same module. That would make it very difficult to reason about the contents of a file on its own and would also be harmful to incremental compilation.
I think the proposed spelling is both concise and clear ("if you import M with access level L, then you can use M's types in the signatures of your own L or lower declarations") and I don't think we'd gain clarity by making it more verbose. public import will be very common in Swift 6 when using imported APIs as part of your own, and I'm not convinced that the use of pub(lic) by other languages to mean @_exported is evidence enough that we should use public import for that in Swift and have to come up with another, more complicated way to spell the proposed public import.