To be honest I think each language should play to their strengths and only "steal" things that benefit their current market of users and how they work. If it augments them that's fine. Otherwise you risk cluttering the language with too many ways to do things. If you want all these F# features you probably just want F# - its not too hard to call `dotnet new classlib -lang F#` these days and mix both in together in a solution.
Having worked in a few C++ shops, at least from my experience, it can result in a lot of useless debates and internal wars if you keep on adding different features from different paradigms into the language whilst trying to keep backwards compatibility.
My view is that if you want unions/non-nullability/data vs classes even if C# gives you the features, it feels more natural to code that way in F# due to the environment around the features and years of optimising that code path. It's just less noisy and less workaround'y. i.e. each language typically prioritizes enhancements and features based on what users in that language are having pain points on. In that sense F# is much further on the data/function paradigm than C# is - conversely when doing low level stuff C# is often in front having to cater for that for some time.
In fact, I've defined it and occasionally use it in F# when I'm working with extensive C# fluent APIs, because it looks nicer than breaking them up with a single |>.
C# Fluent API's aren't really piped things since they usually just mutate a variable underneath (hence the ignore often at the end of them in F#). I don't think fluent API's and piped functions are the same thing, and the pipe operator allows any function that matches the signature to be put in.
The only thing is you don't get exhaustive type checking, now depending on how passionate you are, that can be a must have, but I actually don't mind without.
One of the big lacking things for me is the lack of being able to make types from basic types, sort of like a typedef in C++. F# allows you to do it, but it actually fakes it as .NET itself has no concept of this. This is a PITA if you want types for things like CustomerId which is just an int, but you want it such that CustomerId is typed and can't be passed to other places that would take an int, only if places that take that type. You can model it with a record, but it becomes a bit unnatural and makes mapping it to datastores more effort.
There's a few more things I think they could steal from F#
- a way to do pipe operators - Type providers like https://fsprojects.github.io/FSharp.Data/ - computation expressions (monads without the drama)