Not everything is order independent.
Plugins should indeed be written order-independently, so that they either react to another plugin being applied in the past or future, or applying the plugin directly if it is always needed.
But the statements within one build script always were and always will be order sensitive.
For example you first have to create a configuration, before you can declare dependencies on it.
Or you first have to create a source set before you can declare a feature from it.
And so on.
- the
java-test-fixtures provided a special dependency feature to be consumed by other projects in the same build
Not only in the same build, test fixtures by default are also published, so you can also depend on them from outside the current build if you don’t turn it off.
but I can’t seem to find out how this should look like for jvm-test-suite suites
One has nothing to do with the other.
The test fixtures feature provides a mean to provide some classes - typically test fixtures or test utilities - that can be consumed by the same project, or by other projects inside or outside the current build within their tests.
The jvm-test-suite plugin is to have multiple test suites like unit tests, integ tests, functional tests, load tests, that are clearly separated.
They are by default not meant to be depended upon, but to contain tests that are executed.
But if you insist, you can of course define feature variants for those source sets as you already discovered and then depend on them.
So overall I am kind of confused about the relationship or the future of the java-test-fixtures vs jvm-test-suites plugins.
As I said, they are two completely different things with completely different purposes that can nicely work together though, and that are most probably both are there to stay.
Maybe it’s not the time yet to apply the test suites in my scenario (requiring unitTestFixtures, unitTests, integrationTestFixtures and integrationTests) but I was actually hoping to be able to achieve that already without depending on external plugins (or having to deal with a whole lot of configuration).
The test fixtures plugin only provides one test fixture per project.
But it is actually just some convenience sugar for defining a feature variant, so you can pretty easily do it yourself.
Just create a source set for your additional fixtures (I wouldn’t use a test suite for that, as test suites are meant to contain executable tests and get tasks for executing them and so on, not to provide test fixtures).
Then declare a feature variant from that source set.
And on the consumer side, depend on the capability of that feature when needing the fixtures.
So the question is, what’s the gradle way of doing it
As I described above, you practically found the Gradle way already, except maybe with a separate source set, not the test suite. Except you also have tests in there that you want to execute in your project while still depending on them from somewhere else, but that feels a bit like a mix of responsibilities. (Hence by default the separate plugins for test fixtures and test suites)
and do you maybe want to update the documentation to provide a crystal clear view on the approaches that will be future proof?
If you feel it is not clear enough, you should open an issue or pull request over on GitHub, so that the Gradle folks can consider it. This is a community forum where mostly users like me are helping other users.
It might also be worth opening a feature request so that the test fixtures plugin could create one fixture feature per test suite and not only one for the default test suite, either always or configurable.
having multiple targets
Unfortunately, that is actually not yet possible but something to come. Currently you can only have one target per suite.
and arguing to not use the global dependencies block anymore
I wouldn’t call it arguing, you can still use the global dependencies block.
It is mainly syntax sugar and help for the Kotlin DSL.
Because in the test suite dependencies block, you can use implementation, runtimeOnly, and so on.
In the global dependencies block you would need to use integrationTestImplementation, integrationTestRuntimeOnly, and so on.
And as those configurations are not created by applying a plugin, but by additional configuration of the plugin in the build script, there are for example no type-safe accessors for those generated for Kotlin DSL, so you would first to get them by name for Kotlin DSL or use the string-y version "integrationTestImplementation"("...") which both is too cumbersome when you can just do it in the test suite dependencies block.
and it got no significant updates since it’s introduction, right?
Depends on what you call significant 
and most important for me i- t’s missing the artifact building and distribution feature.
Well, as described above, that is not “missing” but just not the right responsibility by default, which you can realtively easily change. 
Btw., this:
Could not find method call() for arguments [interface org.gradle.api.plugins.jvm.JvmTestSuite, build_bp1rs6g1bwg6xxynjkqddzgl9$_run_closure1$_closure4$_closure5@2b2b926c] on source set ‘integration test’ of type org.gradle.api.internal.tasks.DefaultSourceSet.
is one of the major reasons I recommend using the Kotlin DSL - which now also is the official default - instead of the Groovy DSL. You instantly get type-safe build scripts, actually helpful error messages if you mess up the syntax instead of unhelpul errors like the one you showed, and amazingly better IDE support if you use a proper IDE like IntelliJ.