Generally a Gradle multi-project build can have any layout in the filesystem and it does not need to be hierarchical.
But it seems SQ now demands that paths of sub-projects are below the root-project path and errors out if this is not the case.
Of course it is maybe not feasibly to support any project layout automatically and if some project uses fancy layout they also have to make sure the SQ properties are set properly.
But I’d say that at least flat-style multi-projects that follow the Gradle naming convention and are supported out-of-the-box by Gradle should be handled properly.
This means you have a structure like
/path/to/worktree/master
/path/to/worktree/sub1
/path/to/worktree/sub2
and the sonar-scanner-gradle plugin will set the sonar.projectBaseDir property to /path/to/worktree/master which will then error out when analyzing the subprojects with something like Caused by: java.lang.IllegalStateException: Dir /path/to/worktree/sub1/src/server/resources/META-INF should be relative to project baseDir.
It might be tempting to just set it to the parent directory if it ends in master, but this might also not be correct, e. g. when you have different worktrees for different branches and checked out the master branch into a directory named master. For flat-style project this would end up like
/path/to/worktrees/master/master
/path/to/worktrees/master/sub1
/path/to/worktrees/master/sub2
and thus work with that logic, but for historical-style projects it would be
/path/to/worktrees/master
/path/to/worktrees/master/sub1
/path/to/worktrees/master/sub2
and there having /path/to/worktree/master would be correct.
So for a correct automatic approach I guess you should get the project directories of all projects, find the deepest common directory and use that as root sonar.projectBaseDir and error out with a request to set them manually if no common directory can be found. (Rather rare edge case probably where projects are on different drives on windows)