Is your feature request related to a problem?

Since we enabled the Cucumber API to run the tests in #11069 ( and #11067, #11065 , #11010) we are disabling the native parallel implementation for Cucumber, meaning that for each WDIO worker, we invoke runCucumber and create an entire Cucumber test run.

That introduces many redundancies when taking advantage of many built-in features of Cucumber.

• If enabled with option publish, each WDIO worker indirectly publishes a Cucumber.IO report, instead of having just one per WDIO test run
• Any formatters/reporters that users specify in the configs Cucumber options will generate a set of different outcomes and consolidating that data is either not feasable or not small of a task (i.e. 20 specs trigger 20 HTML reports)

List of native Cucumber formatters/reporters

We should take into account that Cucumber hooks can and often do reference the @wdio/globals, therefore on top of importing support code we must pass this context to the workers as well, otherwise we can run into reference errors such as

Error: No browser instance registered. Don't import @wdio/globals outside of the WDIO testrunner context. Or you have two two different "@wdio/globals" packages installed.
    at Object.get (file:///Users/user/repos/repo/node_modules/@wdio/globals/build/index.js:15:23)
    at Scenario.doStuff (file:///Users/user/repos/repo/e2e/steps/hooks.steps.ts:49:36)

We must also consider aligning the WDIO retry mechanism with the Cucumber retry mechanism.

Describe the solution you'd like.

It should just work, no redundancies should be in place.

When WDIO users specify X maxInstances, the Cucumber parallel optional should be enabled and a maximum of X Cucumber workers wrapped in WDIO workers should run seamlessly.

Describe alternatives you've considered.

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct