You are indeed right that I don't put anything in the lib folder, and instead add stuff into the tools folder. In my example auto-detecting this scenario would work.
Of course the problem with this approach is that I have to manually stipulate what goes into the tools folder when building from a project (which I need to do because it is itself dependent on frequently changing NuGets). Ideally I'd want the ability
to either allow the NuSpec to override the project output destination (I may raise another suggestion for this as a follow on from Proposal 1), or to allow the files to be placed automatically
in the lib folder and the references to be removed via a NuSpec (as in Proposal 1).
What about the situation where I create an instrumentation NuGet, that once included in a NuGet should be included in any NuGets that include that NuGet (take PostSharp for example - although this does have PostSharp.dll in a lib, if you created an instrumentation
NuGet that didn't require this, but had the same kind of need to alter the build of downstream NuGets then your automatic idea would break the build process.
Further to comments I made in Proposal 1 there is a danger in assuming we can anticipate every use case. If an automatic step is added then there should be a way to override it. I
think this is sufficiently edge that it won't occur frequently enough that people will remember the behaviour and as such if it were automatic it is likely to result in confusion and unspotted bugs. If someone needs to prevent dependencies being added
automatically in downstream NuGets they would search for a solution and find the <DoesNotCreateDependency /> (or perhaps better '<DoesNotAutomaticallyCreateDependency />'.
Secondly if the dependency is erroneously removed automatically, you would have to add it back with a <Dependency> node in the NuSpec. The <Dependency> node requires a version number, and so you would have to maintain the NuSpec version
number which would be a real pain in automated processes.
In short I'm not sure there's enough justification for a Convention to exist here instead of just simple Configuration.
Finally, if we also implement a property tab, it would be easy to see the option to switch on 'DoesNotAutomaticallyCreateDependency'.