But then I'd have to manage different aspects of my package metadata in separate files, when it may be conceptually all part of the same thing.
But you're right, I could have an extra file in the package, say, vsautomation.xml, and invoke a dependency-provided command to process it:
<dependency id="FancyVsAutomation" version="1.0.0" />
and install.ps1 could have a single line like:
Process-VsAutomation $installPath, $project
Still feels like some out of the box extension processing should be possible and cool, so that package authors can just declare their dependency and leverage plain markup to make things happen.
Say the "FancyVsAutomation" had a powershell hook to say "I can process extensions of namespace http://foo", and NuGet would automatically call it on init/install/uninstall of any package that uses extensions in that namespace....
I think it could be pretty powerful to add mini-dsls via XML that can be easily implemented in powershell by extension authors. Just brainstorming :). I can give that full automatic thing a try if you think it's worth it.