AMD means something like "your engineers can raise jira tickets related to the supercomputer you bought". The general idea outside of that context seems to be "support" means "can run stuff on the GPU". There's some analogy to games dev - if call of duty doesn't run on an amdgpu, you also don't get to complain to AMD about it, but the games studio certainly will do. The games studio is the entity with the contact details.
ROCm is fairly likely to run on unsupported consumer cards if you build the libraries from source or use them from someone who did, which is just about viable from linux distributions now. You don't get to raise official jira tickets about it when it falls over because it's "unsupported". You'll have a moderately bad time if you ignore the docs recommendations about the kernel version for a given release, or if the difficult task of building the libraries from source goes awry.
The established packaging idea of only shipping machine code libraries for a subset of the GPUs you sell, and giving very limited information on how to make those libraries exist for other GPUs, is obviously making essentially everyone very pissed off with AMD. Their engineers are aware of that and disagree about what to do about it.
I personally think that'll resolve itself once Debian packaging is generally usable. People will install ROCm from their distro instead of from the official builds which don't have machine code for gaming GPUs anyway. That will give rise to new annoyances but at least the applications will try to run on whatever GPU you've got locally.