None? That's not what they are arguing against. You can see and compile the F# code, but since you need for that to use an already built compiler provided by Microsoft, you need to trust it.
Even compiling the compiler and then use that compiler to compile your code doesn't help, because the first compiler that was compiled by someone's else might tamper the resulting compiler binary.
So why are you still looking for issues when there's solutions avoiding their stated objection?
> Even compiling the compiler and then use that compiler to compile your code doesn't help
So what's the threat model now? that MS will risk their reputation, established business models and subject themselves to liability to poison the bootstrapped compiler to detect when a modified F# compiler is being built so they can inject vulnerabilities into all new modified F# compilers ensuring they're similarly poisoned whilst avoiding detection from easily disassembled byte code (that can be crossed checked against its original source), Does that sound plausible?
That's not an answer, you are building the compilers and tools from source, the only reason not to trust the builds of a cloud hosted build environment is if you believe Microsoft is maliciously poisoning builds of OSS compilers its compilers build in a way that escapes detection from its easily disassembled byte code of the compiler and everything it generates, including other modified F# compilers it builds which has to somehow retain its reciprocal poisonous code - all undetected.
