You mostly have to look at the time frames between C# adding features with new ABIs and the time it takes for F# to announce they can actually consume them. Fo

You mostly have to look at the time frames between C# adding features with new ABIs and the time it takes for F# to announce they can actually consume them. For example, F# used to crash the CLR with InvalidProgramException when setting C# `init` properties. [1] It took almost three years, I think, to release the fix. [1]: https://github.com/fsharp/fslang-suggestions/issues/904 https://github.com/fsharp/fslang-suggestions/issues/904 Another rough example would be spans, and their more general feature, byref-like types (ref struct). These required plenty of compiler support, as they've got special lifetime rules (and more pending to implement `scoped`), they are banned as generic type arguments, and they require ignoring a special Obsolete attribute. While these were added to F# timely, many language features still break when they interact with them: local functions, computation expressions (even the built-in ones), recursive type inference, and generic intrinsic methods such as `raise`, `defaultof` or `typeof`. This wouldn't be so bad if C# hadn't "spanified" the shared framework and the entire ecosystem without CLS alternatives for many APIs. So, these natural F# snippets don't compile: let numbers = [| for span in text.EnumerateLines() -> Int32.Parse span |] let checkNonEmpty (span: ReadOnlySpan<'T>) = if span.Length > 0 then span else failwith "Expected non-empty span." Edit: And I haven't even gotten into the libraries that use reflection expecting you to declare types in ways F# doesn't support.