Good news!
Does this mean it is not valid to expect the counts to be matching for every files between SL & SQ?
The only difference should be the taint vulnerabilities as mentioned and explained above, plus other cases mentioned in the FAQ linked previously.
What will happen when the vice versa happens ie. SL produces more count than SQ - developer will spend time to fix a issue which are not going to be reported by SQ.
Now that you have fixed the analysis properties and correctly use the Scanner for Maven, this should not happen anymore. You should always have more issues in SQ than in SL.
FYI we are currently working to bring taint vulnerabilities in the IDE (they will be fetched from the server). This could help with your concern that the developer might introduce a taint vulnerability without knowing it in the IDE.
As per breaking the build, there is a way to do it but we are pushing more and more to use other solutions. I don’t know what you use as an ALM (GitHub, GitLab, Azure DevOps, …) but we generally recommend to analyze at the pull request level (and your edition of SQ supports it). This way you can benefit from Pull Request decoration: your SonarQube server would automatically add a comment on the PR to show a summary of the analysis, to let developers know what is the status of the branch, if they introduced new issues and at what level the coverage is.
There is also a possibility to configure your repository to block the merge of the Pull Request while the Quality Gate is failed. There are some tutorials to configure this: GitHub, BitBucket, Azure DevOps, GitLab. This way the branch cannot be merged if it doesn’t meet your quality criteria.
If you have more questions about these last 2 paragraphs, I encourage you to open a new thread in the Get Help > SonarQube section.
I hope this helped, and thanks for your patience along the whole discussion.
Damien