Conditional update UXes today are built around the assumption that when an update is conditional, it's a Red Hat issue, and some future release will fix the bug, and an update will become recommended. On this assumption, UXes like oc adm upgrade and the web-console both mention the existence of supported-but-not-recommended update targets, but don't push the associated messages in front of the cluster administrator.

But there are also update issues like exposure to Kubernetes API removals, where we will never restore the APIs, and we want the admin to take action (and maybe eventually accept the risk as part of the update). Do we want to adjust our update-risk UXes to be more open about discussing risks. For example, we could expose the message for the tip-most Recommended!=True update? Or something like that? So the cluster admin could read the message, and decide for themselves if it was a "wait for newer releases" thing or a "fix something in my current cluster state" thing. I think this would reduce current confusion about "which updates is Upgradeable=False blocking?" (OCPBUGS-9013) and similar.