Hello @Zer0ne,
I think there’s a misunderstanding on what we mean by supporting monorepos.
Generally speaking our understanding of monorepos is that they are a collection of separate projects that can be built separately, but are in the same SCM repository to better manage dependencies between projects (avoid dependency hell).
Currently, with SonarQube you can already analyze projects in a same monorepo. The right way is to split the analysis of the (relatively) independent projects as separate projects in SonarQube (each component of the monorepo that can be built independently=1 independent scanner run=1 project in SonarQube)
When we have a problem is specifically on pull request decoration. Currently each successive PR analysis of the same PR (but from different components of the monorepo) overwrite the findings of the previous one. This is not suitable because you probably have developers working on different areas of the same PR in the monorepo.
So for us, the support of mono repo means that every constituent (sub)project (that is analyzed independently of the rest) of a mono repo will decorate its “piece” of the PR without overwriting the decoration of another piece of work in the same PR of another (sub)project
Does that make sense?
As you properly stated, the above described capability is not yet available in SonarQube 8.6, it should come soon (with 8.7 normally)