Currently scriptcs uses /packages, /bin and packages.config. These are susceptible to name clashes in some scenarios, e.g. a scriptcs based build system such as Bau or Shovel will typically have a .csx in the solution root so the /packages folder for the solution will clash with the /packages folder for scriptcs. Another scenario is descibed in #618. It's also common to use /bin for other purposes, e.g. in my day job, all builds write their resulting artifacts into /bin. Regarding packages.config, it's not unreasonable to imagine scenarios where someone might want to do some scripting within a .NET project folder, so there would be a name clash with the project's packages.config.

nodejs uses /node_modules, which almost certainly guarantees that nodejs can operate in any scenario, isolated from the file system environment in which scripts are located. Following that pattern, and to avoid clashes with a .NET projects packages.config, I propose that scriptcs changes to using /scriptcs_packages, /scriptcs_bin and scriptcs_packages.config.

There are other issues for allowing custom script pack and module paths (#618 and #625). If they are implemented then /scriptcs_packages and /scriptcs_bin would simply be the defaults, instead of /packages and /bin.

I concede that the proposed names are a little long and slightly ugly and I almost feel reluctant to suggest them but ultimately if we want to allow people to blend together the two ecosystems (regular .NET and scriptcs) in weird and wonderful ways then I think this change is necessary. Alternatively if we do implement #618 then we could leave it to CLI tool authors to document where script packs should be installed but this would add some friction for users of those tools and it wouldn't solve the packages.config clash. At the moment I'm keen to explore if we can offer an experience closer to nodejs for tools like gulp and grunt, where things like this don't need thinking about by users.

This will prove disruptive in the sort term since current users will have to do some renaming (we could provide a -migrate CLI switch) but I think it will remove a lot of friction in the long term in supporting build scripting and other scenarios. If people agree then the sooner this change is made before 1.0, the better.