I have changed a default behavior in Vault to include *.config files in source control. which I believe is the root of the problem, but it's a very broad scenario with lots of good reasons to change the default so I don't believe a deadlock is a desirable way of handling it.
Starting with a new project bound to Vault, use NuGet to add any package. NuGet will add a "packages.config" file to the root of your project. Because I include *.config files in source control, this file is tracked and flagged as "pending add".
Side Note: If you attempt to add/remove NuGet packages and do not have packages.config checked out, NuGet will fail. I think that's a NuGet issue though with them not making any assumptions about whether the source control provider flags files as read-only. For this example, assume packages is either checked out, or still pending add.
If you use NuGet to remove the last package it's managing, it will attempt to delete the packages.config file, as it's no longer needed. During the uninstallation process, the NuGet dialog box is displayed modally. Removing a file triggers Vault to prompt for confirmation. You can't confirm because the NuGet box controls the UI. You can't continue/abort the NuGet operation because it's UI is blocked by what it assumed would be a simple call to the file system to delete the file. It wasn't expecting to block.
I've looked through the configuration settings and can't seem to find an option to disable Vault's delete confirmation. I realize that Vault is only trying to keep me safe and protect my files, but deadlocking VS isn't my first choice in how to handle it
Any thoughts? I'm also submitting this to the NuGet team to see if they can approach it from the other side by properly interacting with the source control provider and/or not using a model dialog box.