Well, if the language was only meant to be an API consumer then eliding OO stuff would make more sense, but they designed it for bi-directional interop. And besides, F# was based on OCaml (as I'm sure you know), which itself was an existence proof that you could successfully bolt OO onto a functional language.
Yes, I think that's a good description. It's not great, but it somehow works (although the whole F# community tends to tell people to stay away from OOP when not necessary).
Would have been interesting to explore better ways to support OOP so that it doesn't need to be considered a second class citizen, but I guess it's too late for that now.
There's an enormous difference. And it's a good thing F#'s designers chose the latter option; it's a huge win on the interoperability front. Libraries have a tendency to be write-once-use-often, so exporting object-oriented APIs from F# code is way better than consuming functional APIs from C# code.
I think there is a huge way between allowing developers consume F# code from C# and importing all the ugliness of stuff like static members into the language. I don't think it has to be that way.
What's the value of having a runtime with a language-independent intermediate representation if one just adds half of C#'s complexity into F#?
