I'm sorry, but what you're saying is factually incorrect. Can you please update your comment so as not to spread misinformation?

Updated with the blog quote.

This is for the .NET Core tooling support part of F#, and as we've stated in the blog post, we prioritized the quality of cross-platform usage here. You're free to disagree with this prioritization, but please don't craft a narrative about the relationship between F# and Microsoft that can mislead people as you did before.

If the issues faced by your team were related to C# I assume management would have taken other path.

And this is the reason why none of our customers wants to even discuss integrating F# into C# projects.

Perhaps it's worth taking a different viewpoint. With VS 2017, no single release updates every part of the product to the latest things. For example, UWP does not support .NET Standard 2.0 yet. That did not put the VS 2017 15.3 release on hold. Similarly, although F# fully supports .NET Core and .NET Standard 2.0 with this release, the tooling quality wasn't high enough for us to declare the associated tooling support in VS as fully supported. That also did not put the VS 2017 15.3 release on hold. This because we're already three updates into Visual Studio, and it's only been 6 months since its release. Visual Studio updates faster and teams can release things easier and more rapidly without needing to wait for everything else. This is a really good thing.

Point taken, but apparently Microsoft employees keep forgeting F# is part of .NET, or isn't EditorConfig at all relevant for F#?

https://docs.microsoft.com/en-us/visualstudio/ide/editorconf...

This, and also VS2017 did in fact ship C# without some things (for instance, full support for value tuples).

This is minor compared to all the major things VS isn't shipping for many years in a row now.