You don't really need to split 1 & 2, since F# can define .NET interfaces and abstract classes just fine.

For that matter, you don't even need the interfaces if you wouldn't have had them in a C#-only solution. Just define the class in F# and use it directly from C#.

You still need a separate assembly for F#, but that doesn't imply dependency injection - again, just reference it and use it.

I've identified a possible use case for F# in a preexisting product; I'm looking for the simplest way to integrate F#.

F# excels in writing ___domain logic where main ___domain entities are defined as records and discriminated unions and logic is written in pure functions. Given that product is preexisting and ___domain entities must already be defined, I wonder what use case do you have in mind?

Realtime control logic for infrastructure.

The basic decision making logic needs to be very simple and easy to follow by scientists and people who aren't day-to-day software engineers: Basically, input some data, such as sensor readings, run it through an algorithm that makes decisions, and then output the decisions.