Okay, so: our Visual Studio project contains a build step in which it copies files to a mapped drive, and we got funky behavior after the team upgraded to Windows 10. This behavior basically made it look like the destination wasn't there or that we didn't have access to it.
It turns out that if you run VS as a regular (unelevated) user, which we'd forgotten you really shouldn't do, then you may not have write access to the resource. One way to address this is to net use the resource in your build script, before the line where it copies the files.
For us the key, which it took a while to realize, is that when using a mapped drive, you have to be sure that you have mapped the drive as the same user that VS is running as. So, if you run Visual Studio as administrator, you may need to map the drive (net use x: \hostname\share) in an administrator command prompt in order for it to work.