> Beyond that, [it] doesn't cooperate the way you'd like it to I know what I would like it to do. There are some additional features that people would like to

> Beyond that, [it] doesn't cooperate the way you'd like it to I know what I would like it to do. There are some additional features that people would like to use (https://github.com/fare/package-renaming https://github.com/fare/package-renaming), but even though the package system could be improved, I don't think it is so bad right know. It can be frustrating to try to use it in a way it wasn't designed. I seldom use qualified symbols, so it is generally "(bar (foo x))" anyway. The case when fully qualifiable symbols might be the best solution is when you need symbols with the same name from different packages at the same time (without shadowing), which is quite rare IMO. Also, defining short packages as a facade for other packages is possible. When you develop an application, not a library, you can also choose to mess things up by renaming packages and adding nicknames. By using unqualified packages, I can change the meaning of the code by editing only the package definitions (and recompiling): you code says `(foo x)` and originally meant `(a:foo x)`, but then you change a package and now it means `(b:foo x)`. For example `b:foo` could be a wrapper around `a:foo`. Packages prefix help a little when trying to understand where a symbol comes from. For example, "json:decode" is a little easier to read than "decode". However, with the right editor (or just the REPL) you point to the symbol and have the information.