So basically in RHEL 8 this issues was fixed by reverting upstream changes after the RHEL 8.3 Anaconda rebase to match RHEL 8.2 behaviour. This was actually needed as the "Lock root account" checkbox was not visible (removed as requested in bug 1819844) so it was not possible to make the root password entry sensitive again.

But on RHEL 9 the "Lock root account" checkbox is actually visible so unlike on RHEL 8, this situation is recoverable - the user just has to uncheck "Lock root account" and the root password entry would be sensitive again. 

Also the entry being sensitive even with the checkbox being ticked on first spoke entry is actually by design, as there is an expectation that if the root password spoke has been entered the user most likely wants to set the root password (given there is not much else to be done on the screen) and it should be as easy as possible. On subsequent visits this UX optimization is no longer applied and the checkbox mass directly to root password entry sensitivity.

To summarize, the observed behaviour is valid upstream Anaconda behaviour, not really a bug. It's indeed also a slight change in behaviour from RHEL 8, but given RHEL 9 is a new major release that already includes significant changes in root password handling (password based root login via SSH will no longer be possible, see bug 1855736) I'm not sure the additional work & divergence from upstream needed to restore the RHEL 8 behaviour is really needed.

And lastly, there is actually an upstream discussion going on about improving the overall UX of the root password spoke: 

https://github.com/rhinstaller/anaconda/pull/3262

It might be a good idea to see how this discussion ends up and possibly backport the changes instead if the resulting UX is judged better than what we had in RHEL 8 & 9.

(In reply to Martin Kolman from comment #2)
> On subsequent visits this UX optimization is
> no longer applied and the checkbox mass directly to root password entry
> sensitivity.

Well, this sounds like inconsistent behaviour hence bug to me.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

I'm reopening this bug, as it is still present (RHEL-9.2.0-20221122.2) and, as it introduces an inconsistency in the UX (active password fields when entering the spoke for the first time, but disabled for the second time), I think it deserves to be fixed.