Seems reasonable by definition, but it’s also a rarely seen bug, and these are often extremely hard to find. Only report in forum or issues appears to be this, and your Backup failure: Detected files associated with non-existing blocksets #3850. Have you found others? In the source of VerifyConsistency, this self-check appears just below another that’s seen more often, but still has never been reproducible reliably by either users or developers. I can point to some debug methods. Long and latest is below, but there were others:
Fatal error: Detected non-empty blocksets with no associated blocks
Can you inspect and post the default backup log from the last seemingly successful backup or operation? Because the database is verified before further use, the verification sometimes finds errors added earlier. Ideally preparing for analysis of a problem would have copies of the database before and after corruption, along with hugely detailed logfile, but that’s too heavy to be done routinely unless one is chasing an issue.
You could consider posting a link to a database bug report which is pretty well sanitized for path names in 2.0.4.5 or 2.0.4.23 beta (basically the same), but less so in some other canary and experimental releases. Possibly that would offer some slight clues on how things got how they are, but there’s often no substitute for being able to reproduce the problem on a developer’s system where they can examine it as they wish. This is really what a GitHub issue would prefer in “Steps to reproduce” – how to reproduce it from scratch.