Many languages have the feature to import just one thing at a time out of a module that imports many things:
import unzip from <ZipModule>
import zip from <ZipModule>
Most would let you use a list:
import [zip unzip] from <ZipModule>
And some languages would let you use wildcarding...or at least the wildcard of "give me everything"
import * from <ZipModule>
But people have traditionally looked down on this practice... because it means that arbitrary additions to the module in the future could start conflicting with your code that had previously worked.
Instead, what people suggest doing would be to namespace the whole thing, and store it in a variable:
zip-stuff: import <ZipModule>
This would give you everything ZipModule exported...but as zip-stuff.zip and zip-stuff.unzip and zip-stuff.xxx. So it means your client code is still in control.
JavaScript doesn't just advise against import *, they prohibit it...
Plain "import <ZipModule>" does not exist in JavaScript. Every variable you import from the module needs to be named, and if you don't feel like naming everything you have to name just one thing to contain them all.
One of the reasons I'm hesitant to bring back the case-insensitivity is because when you work in a modularized world, it's very frequent that people want to do things like use uppercase capital letters to name the modules. So along these lines:
N: import <NewPrint>
Z: import <ZipModule>
repeat n 10 [
N.print ["Unzipping file" n]
let filename: as file! unspaced ["zipfile" n ".zip"]
Z.unzip %unzipped/ filename
]
This isn't so common in JavaScript. But it's basically the dominant style in Haskell and Elm.
Even if you aren't a fan of the convention, it's fairly heavy-handed to say that no one can use the style. Dealing in the domain of limited typewriter-space, taking away distinguished capital letters is a pretty big loss.
I think we should very seriously weigh what the value is of saying that plain code is case-insensitive. Dialects could still be implemented case-sensitively. Anyway, issues surrounding the question are still percolating...back to the question in the title.
We Probably Want To Avoid Too Much Prescriptisim
We definitely shouldn't prohibit "import *" semantics.
Particularly when you're trying to make a language where you can abstract ideas like variable declaration (see for instance TLS Emit)....then there could be all sorts of "import-like" abstractions which magically make groups of definitions appear for you to use...generated programmatically if necessary.
What we might want to think about is whether or not we want to make it so easy to do that people assume they're supposed to do it. If saying import <ZipModule> is how you get zip and unzip added for use, people are going to do that...because it's easy.
There are jarring choices like import/unsafe <ZipModule>...but that is pretty nebulous on what's unsafe about it. More specific might be import/pollute <ZipModule>.
I think I'd suggest the thing to do is probably just to establish some sort of self-consciousness about it so it's not something that happens as a complete default. The easiest thing to do should probably align with a "good practice".