I think one thing that would hlp with your first point would be to add a new option to nimble, such as nimble install --save tempdir (using one of my packages for example). This is stolen from NPM (node's package manager) which uses both \--save and \--save-dev to mean that the package argument is added to the package.json file (or <xyz>.nimble in Nimble's case).
In addition to what you've mentioned, Nimble also really could do with having the ability to vendor packages within a package/application rather than always relying on a global package store. Go have struggled with taking the approach of installing places globally and they still haven't fully fixed it (though they recently added stuff to their package manager to vendor stuff, in the meantime several third party alternatives such as [govendor](https://github.com/kardianos/govendor) and [gom](https://github.com/mattn/gom) have sprung up). Without vendoring, I can very easily release a v1.0.0 tag which you might then install - there's nothing stopping me from then later moving that tag to an entirely different commit and force pushing it to the repository. With vendoring, you can always check in the _exact_ package versions you're using to build your application. Lock files would also be great, and I know they're on **@dom96**'s roadmap of things to get around to.
