Q1 :what happens if 2 nimble packages with same name are published to nimble? eg: [https://github.com/ivankoster/protobuf-nim](https://github.com/ivankoster/protobuf-nim) [https://github.com/PMunch/protobuf-nim](https://github.com/PMunch/protobuf-nim)
I don't see any package name uniqueness constraint mentioned here: [https://github.com/nim-lang/packages/blob/master/README.md](https://github.com/nim-lang/packages/blob/master/README.md) Is package name collision prevented by nimble publish, or enforced in any way? Q2: what happens if 2 nimble packages (whatever their package name) define the same module? eg: these [https://github.com/ivankoster/protobuf-nim](https://github.com/ivankoster/protobuf-nim) and [https://github.com/PMunch/protobuf-nim](https://github.com/PMunch/protobuf-nim) both define module protobuf; so what will import protobuf import if both packages are published and installed (in the future, since now they're not on nimble)? Q3: to mitigate module name collision, could we require/encourage packages published on nim to either be a single module or multiple modules but under a package foo? [https://github.com/nim-lang/packages/blob/master/README.md](https://github.com/nim-lang/packages/blob/master/README.md) doesn't mention this Q4: on a related note, the standard library puts a ton of modules on the global top-level namespace, which could lead to name collisions. Lots of other languages (eg C++, D, rust, C#, etc) use a package (typically std) to avoid this. Why not use that in Nim? eg, using import std.typetraits instead of import typetraits ; nimfix or anoother tool could help with migration and aliases could be used during some deprecation period.
