When would you choose SpecFlow/Reqnroll over Cucumber-JVM for a.NET project?

Cucumber-JVM specifically targets the JVM; running it directly isn't a natural fit for a codebase built on .NET, since the step definitions would need to be written in a JVM language and the test execution wouldn't integrate cleanly with .NET's own build and test tooling (MSBuild, dotnet test, Visual Studio Test Explorer).

Reqnroll (SpecFlow's actively maintained continuation) is designed specifically for .NET: step definitions are written in C#, it integrates with the standard .NET test runners, and it fits naturally into an existing .NET CI/CD pipeline without introducing a JVM dependency into an otherwise pure .NET stack. For a team building on .NET, this is a straightforward choice, not really a close call, since the alternative would mean maintaining a second language runtime purely for testing.

The one scenario where reaching for genuine Cucumber-JVM makes sense in a .NET-adjacent context is testing a JVM-based service from within a broader polyglot organization that already standardizes on Cucumber-JVM elsewhere and wants consistent tooling and reporting across both .NET and JVM services, accepting the added complexity of a secondary toolchain for that consistency.