Jetbrains have a project to try and replace Gradle.
I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first.
Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.
It’s both now.
https://gradle.github.io/declarative-gradle/
Fingers crossed.
I've long since given up on Gradle being able to get this stuff right. The syntax they're proposing is the THIRD similar-but-incompatible syntax they've adopted after Groovy and Kotlin. Good luck figuring out which is in use by looking at a code sample.
The biggest problem with Gradle is not Kotlin or even Groovy syntax. Kotlin isn't a bad language to use even for writing configuration. It's that the entire thing is designed in extremely confusing ways from back to front, and has a lot of awkward design choices and bugs that result in a hyper-complex user model.
What the JVM world needs is a totally new tool that has the same feature set as Gradle but with a drastically simpler mental model behind it. The only real contender right now is Bazel, I think.
We just keep using Maven, there must be valid reason on customer side why we should use Gradle instead of Maven on our Java consulting projects.