Hi @Chris ,
now I have found some time to have a closer look.
indeed, as i wrote above
Going into discussion with the users BEFORE making such decisions would save both sides frustration, anger and the waste of time and resources.
Deprecating features is one thing, but deprecating and deactivating at once is a no go, never experienced that with any software 
Normally deprecating is a marker for “this will change in the future” but i’ll have time to adapt or intervent.
WRT to the clean code approach
What’s the motivation behind this all, i’m more than 100% sure it doesn’t stem from user feedback ?
You’ve already got a lot of (negative) feedback after introducing the prominent " This quality gate does not comply with Clean as You Code" warning, but nevertheless you went further.
Your Clean Code approach in all honor, but it’s your way, we don’t want to be forced to use Sonarqube
like you tell us we have to use it.
Until Sonarqube 10.2 there was enough flexibility for nearly every use case.
The simplifying of severities to high / medium / low is ok 
but taking away the categories and the possibility to change rule severities is the wrong way.
Our security team may have another opinion and wants to increase the severity.
Another example is the rule Java static code analysis: Track uses of "@SuppressWarnings" annotations
In Sonarqube 10.2 it has low impact, but we have severity critical for it.
code smells are whitelisted, but security rules not, see
Where is the documentation on how to suppress each kind of warning? - #3 by Rebse
Developers are used to the concepts of bug, vulnerability, code smell for years - those are established terms and concepts - but the terms of consistent, intentional, adaptable, responsible code are to academic.
Issue type deprecation and severity changes
As part of this change, we will be deprecating and gradually removing our previous notion of issue type (bugs, vulnerabilities, and code smells). Also, severity will have simplified values: low, medium, and high. Additionally, we are extending severity to multiple severities per issue, one per software quality.
Multiple severities per issue adds a needlessly complexity.
For the quality gates, everyone understands conditions like critical issues > 0 at first glance, but if i have to use ratings i need a translation first, what does rating A mean … etc.
After all, i already presented our workflow in my first post and why the changes in Sonarqube 10.2 are a showstopper. Also i have no idea for a migration path, it just won’t work.
Otherwise we’re on the latest Sonarqube version for quite some time, but now …
I sincerely hope you will reconsider the whole thing thoroughly.
Was project manager in 2015 for selecting a tool for code analysis and I was glad Sonarqube made it,
but I don’t want to be project manager again to find a replacement for Sonarqube in 202x.
Gilbert