veqq naming and import response fragments

gistfile1.txt

i do also happen to think that there are conditions under which english (/ human language) name being changed would be better for reasons i mentioned before, but this is less of an issue from the perspective of api breakage / use in codebases.

i think not changing english names can lead to a kind of confusion that i think it would be nice to avoid (cf. firefox situation) in communication as well as being potentially misleading.

searching for things later can also become more complicated by not changing names because one can end up with more stuff to sift through.

---

to clarify a bit of why i don't want to talk in terms of `import` so much is at least partly because it has complexities that make discussion and thought more cumbersome.  listed at [this page](https://janet-lang.org/docs/modules.html) are relative imports, working directory imports, @-prefixed imports, and imports can be customzied a fair bit as well.

it is just much more complex to talk and think accurately at that level.

i think syspath is more straight-forward and simpler to discuss and reason about -- not to mention that it's something that is unlikely to change in major ways any time soon.

---

people have things installed on their systems (in various syspaths) over which we have no direct control so for janet to keep working properly for them the syspath stuff is constrained wrt what kinds of changes can work [1].

---

[1] syspath is one of the things bakpakin kept mostly the same between how jpm and janet-pm work with things (really the `bundle/*` parts of janet itself).

fwiw, he did make `bin` and `bundle` subdirectories of syspath "special" (no one should use these for "library" code installation destinations) when he added `bundle/*` bits to `boot.janet`, thereby "hijacking" those directories for "internal use", but this seems to have worked out so far.  i would have preferred there being some kind of prefix (he did this for jpm with `.cache` and `.manifests`) but this is what we have.

as noted elsewhere, you can still do `(import bin/something)` if `something.janet` lives under `<syspath>/bin` (this can be arrange for via adding a binscript), but i'm not sure if that was intended.  so it seems `bin` and `bundle` are a couple of exceptions to the "rule" that two different packages can't install things into the same "prefix" (read "top-level subdirectory of syspath").

it is possible someone had a legacy bundle that installed "library code" into `bin` or `bundle` but i haven't come across it.  it doesn't appear to be a common thing afaict.