Maybe because it's not a popular language, but the F# experience for me has been bad - tried it two years ago with F# 5, and recently with F# 6. The documentation in both cases was immature/inconsistent to broken.
The usual features (e.g TP's) that are used to sell the language though I feel are oversold and tbh not the main reason F# users like the language - in fact I think TP's need an overhaul and are a distraction. Inlining code for math (which is just getting an equivalent like feature in the next C#), unions/records together, functions and type inference, leaning to compile time vs runtime dispatch in code style, etc I feel are where its strengths are at. More than features I've found for large scale projects its just easier to spot bad code in F#, less bugs have made it ot Production when .NET teams have tried it, and less of it makes it to code reviews.
I've found F# tooling at least for VS Code more stable than the C# equivalent. But that's not saying much - most languages plugins for VS Code don't feel that stable to me if not JS (e.g. the Java one used to crash on me all the time). In VS Studio, Rider, etc are options.
Documentation should be improved sure especially for people getting into it; but it is the smaller language and documentation goes out of date quickly. This obviously penalises the new starter without a mentor/senior dev to teach them in the job/elsewhere.
Early on one of the big selling points was reading all those type provider articles. Then I've tried it a couple of months ago and it was such a broken mess - not worth the time. From what I've read this isn't just my experience.
With, record types, switch expressions, top level expressions, file scoped modules, global usings, etc. C# removed a lot of cruft. Roslyn source generators actually work unlike type providers. If they improved the REPL/scripting aspect of C# I think there would be very little arguments for F# other than catering to FP crowd who like to like |> to |> write |> like |> this instead of this(like(write(to(like))))