@enricosada did it this way to get all the right SDK bits and pieces - targets etc. - into place, I'm not sure

as a note, for new sdk, i dont use the target file from vf# repo. i use FSharp.NET.Core.Sdk.targets, that's where CoreCompile is defined

Is there any reason we can't move both the spec of the FSharp.Compiler.Tools package

for FSharp.Compiler.Tools i dont mind. it's pratically Microsoft.FSharp.Compiler.netcore with some props file to locate fsc.
As a note, i tried initially to do exactly that with my old PR #2250 .
Is the same as having FSharp.Core package here ihmo, why not? i am just merging Microsoft.FSharp.Core.netcore too.
Also for FSharp.Build.dll having that signed from MS is better, because of internal visible stuff.

and the whole of netcorecli-fsc into this repo

Nothing techically, is all about project development.
Atm i can:

• move faster fixing bugs and release packages in other repo
• for speed of the test suite too (i have far more os under test and atm is fast to generate a package).
• i can personally manage issues/tag, manage roadmap for sdk 1.0 rtm https://github.com/dotnet/netcorecli-fsc/projects/2, or releases
• i triage issue from using new fsproj from netcore users (or xamarin, or sdk team), if is a compiler issue i reopen here (like today fsc netcore --help shows pdbonly and full. and --debug:__ ignores these options #2565), if is a fsharp.core bug too.

long term is a good idea to have it near FSharp.Core and FSharp.Compiler.Tools (so maybe in fsharp/fsharp too, just compiler+fsharcore+fcs? 😄 ).
But atm is a bit complicated to do so.