Concurrency issue loading task assemblies

Description

Getting the following error when running a clean build, both locally and on build agent.

    C:\Development\XX\packages\Microsoft.Net.Compilers\tools\Microsoft.CSharp.Core.targets(84,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly C:\Development\XX\packages\Microsoft.Net.Compilers\build\..\tools\Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Development\XX\src\YY\YY.csproj]

This only happens when including paket.targets in the project file.

Repro steps

1. Download attached zip ConcurrencyReproJC.zip
2. Run build.cmd
3. Run build.cmd again (it will pass)
4. git clean -fdx (you'll need to git init first)
5. Run build.cmd again (it will fail)

Notes:

• The first failure is consistent - happens locally and on our build server
• It appears to be either timing or ordering related. I've sometimes had build.cmd fail on the second run too, but never the third or fourth in this test repro.
• If you cut the paket.dependencies & lock file down to just the ones now present in the project files, the issue goes away. So appears to be some interaction with the dependencies/lock file
• Furthermore, switching the build.cmd to target the solution file instead the build succeeds. (In my 'real' case, the solution build fails too, but with many more projects in place)

Expected behavior

Build succeeds consistently

Actual behavior

Build fails

Known workarounds

None

Start with build.cmd and the project file's paket.targets inclusion, then compare the project build with the solution build described in the reproduction. Use ConcurrencyReproJC.zip, the paket.dependencies and lock file, and the clean-build sequence to isolate the ordering or timing difference. Done means repeated clean builds succeed consistently without the assembly-loading error.