The key part of this minimal example is that the solution has one C# project (either old or new style csproj), plus two F# projects (old style fsproj). By "new style" I mean using the modern MSBuild SDK, and by old style I mean the format which predates that.
Builds successfully.
Build fails due to an internal MSBuild Error:
1>------ Build started: Project: fsharp1, Configuration: Debug Any CPU ------
2>------ Build started: Project: fsharp2, Configuration: Debug Any CPU ------
2>Unhandled Exception:MSB0001: Internal MSBuild Error: Already registered for build-time.
2>Error: MSB0001: Internal MSBuild Error: Already registered for build-time.
3>------ Build started: Project: csharp, Configuration: Debug Any CPU ------
3> csharp -> C:\git\ReproForMsbuildAlreadyRegisteredForBuildTime\csharp\bin\Debug\csharp.dll
1> fsharp1 -> C:\git\ReproForMsbuildAlreadyRegisteredForBuildTime\fsharp1\bin\Debug\fsharp1.dll
========== Build: 2 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Note that subsequent builds may succeed, so you may need to run
git clean -dfx
to reproduce again.
Windows 10, version 1803, OS Build 17134.191.
Visual Studio v15.8.0. The issue is not present in v15.7.x.
Weirdly, running msbuild from a Visual Studio command line (VsDevCmd.bat) is successful. I only see the failure inside the Visual Studio GUI.
Finally, there is a thread Visual Studio forum, where others have encountered the issue.
A comment on the VS forum (https://developercommunity.visualstudio.com/comments/311939/view.html):
Looking at MSBuild code, seems to be a threading bug. I reduced concurrent builds from 8 to 1 to work around this issue
This seems to work for me too.
Reducing from 2 to 1 under VS > Options > Projects and Solutions > Build and Run fixed this for me.
Reducing to 1 works around this issue for me as well - but down from 8 to 1 that's an inacceptable performance regression, so it's not acceptable as a solution for me.
Reducing to 1 works around this issue for me as well - but down from 8 to 1 that's an inacceptable performance regression, so it's not acceptable as a solution for me.

Turns out this isn't an MSBuild issue. Progress should be tracked here:
https://github.com/Microsoft/visualfsharp/issues/5504
@AndyGerlicher If you have spare time, could you elaborate how the corrected logic takes care of the intermittent behavior on multi-core?
@gchernis
When the F# project system in VS was doing parallel builds, sometimes it reused the same msbuild logger for multiple parallel builds (not a data race), which caused a runtime precondition check in msbuild to fail. The fix is to not reuse loggers for parallel builds.
Just tried the nightly build of Visual F#. My solution builds fine with 16 cores concurrently. https://dotnet.myget.org/feed/fsharp/package/vsix/VisualFSharp/15.8.20180906.2
Most helpful comment
A comment on the VS forum (https://developercommunity.visualstudio.com/comments/311939/view.html):
This seems to work for me too.