Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that would of never approached C#. I agree that each language has its sweet spot. Looking at their feature sets I think:

- Domain modelling, algorithm, business logic, etc is easier with F# in general. C# is getting better than this, but F# is there and has been there for a long time.

- Integrating with build tooling and generation tends to be C# because these tools were designed for that target (i.e not the language itself). The value is in the tooling and the engineering in that - C# just happens to be the target.

Personally with the above I've found most of the logic tends to be in F# with some C# projects for where the packages needs that build tooling support (i.e. not the language or syntax, but for the tooling or other features of Roslyn). An example would be Grpc.Tools. Most of the time these projects can use generated code anyway so the writing of C# can be kept to a minimum - i.e. not one single C# file in the C# project. Besides I think the learning curve/barrier for a language isn't really syntax, or language features - its the libraries to use, the patterns, the ecosystem, package manager, CI/CD settings, etc. Using F# isn't a large cost once you've learnt all those things that are shared which is way more than isn't.