Bobc is notoriously pessimistic in his predictions and has been right more often than notoriously optimistic other members of this forum
“The first release candidate hopefully some time early next year” (meaning 2021) has been repeated many times, probably because the project leader has said it.
Unfortunately the time between rc1 and the final has been too long in the past. IMO the project should change the naming to what it actually is: nightly builds are alpha, rc1 is actually what other projects call beta1, i.e. new bugs are actually still expected. Release Candidate means usually “ready to be released as is unless new serious bugs are found”, only serious bugs lead to a new RC, and no known bugs have been postponed after RC1, not even a single one. That would make the expectations more realistic and the end of the waiting cycle more predictable in short term.
But that’s a smallish detail. My observations from the past tell that the most difficult problem for the project is lack of good testing. Every KiCad user could help with that. If KiCad would have got more testing before and after rc1 and more of the bugs would have been found earlier than later, the release schedule would have been tighter. As it is now, it has happened that a new bug is found, then a new one, then a new one… and suddenly we notice that 6 months has gone. Even though the version naming with KiCad Release Candidates have been way too optimistic, it would have been more realistic if testing would have covered more and revealed more of the bugs before the RC1.
Everyone can help to shorten the release cycle in this phase (after the feature freeze), and it will actually work. So everyone, please test, test, test, and report bugs. It will make the release cycle shorter and more predictable.