The current "test execution multiplier" or:
generates multiple tests (method executions) under a test class (suite). All these tests, however, are bound to a single class so they must run sequentially and on a single JVM (because of how JUnit works – nesting of rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to be able to run a single suite in parallel, possibly in combination with tests.iters (so that a single test method is executed X times on Y parallel JVMs).
This is surprisingly easy with the randomized runner because it currently accepts "duplicate" suite names and will load-balance them in a normal way. So, if one has Y cores (JVMs) then providing a suite name X times will result in X executions, balanced across Y JVMs.
The only problem is how to "multiply" suite names. This can be done in a number of ways, starting from a custom resource collection wrapper and ending at a built-in code in the runner itself. I think the custom collection wrapper approach would be interesting, I'll explore this direction.