What happens?: Recently, when I perform the regular and essential task of doing an incategory search of https://en.wikipedia.org/wiki/Category:Living_people to search for draftspace or userspace pages that should not be filed in mainspace categories, the search finds a number of phantom redirects where the page in fact isn't in draftspace at all, but rather has already been moved into mainspace -- but the resulting draftspace redirect doesn't have any categories on it, and if you manually eyeball the individual categories that it's in they don't actually show the draftspace titles as being filed in them
For example, today's run of the search at https://en.wikipedia.org/w/index.php?search=incategory%3A%22Living_people%22&title=Special:Search&profile=advanced&fulltext=1&ns2=1&ns3=1&ns118=1&ns119=1 displays the title https://en.wikipedia.org/w/index.php?title=Draft:Kadek_Dimas_Satria&redirect=no. Note that the draft title doesn't have categories in it, and if you look at any of the categories that are on the target page https://en.wikipedia.org/wiki/Kadek_Dimas_Satria, they do not list the draftspace redirect as being in them -- but if you go back and perform an incategory search on each of those categories to look for draftspace pages, the incategory search does still say that Draft:Kadek Dimas Satria is in each and every one of them.
The issue invariably results from cases where an editor applied categories to the page while it was still in draft, and then moved the page into mainspace after adding the categories. So far, the only solution I have found that works to clear the phantom redirects out of the incategory search is to actually move the page back into draftspace, and wrap the categories in the "draft categories" wrapper; this would finally cause the page to drop from the incategory search, following which I could then move the page back into mainspace again and unwrap the categories in mainspace, and the redirect would not then return to the incategory search again. Nothing else has successfully cleared the redirects from the search: null-editing the draftspace redirect didn't work, deleting and then restoring the draftspace redirect didn't work, adding the redirects to a maintenance holding category didn't work.
I never, ever saw even one case of this ever happening at all before February 2023. A couple of weeks ago, for the first time ever, there was one standalone case of it which looked like an isolated problem at the time, but then after I resolved the problem by redoing the page move it did not recur again until March 1 -- at which point it suddenly became an epidemic, with eighteen phantom redirects turning up so far just in the past three days alone. I had already corrected the seven instances I found on Wednesday and Thursday, but with eleven more of them today, I'm at the end of my patience with it.
This also is not just normal lag in the job queue, as real drafts which are in the category inappropriately, and have the category removed or disabled accordingly, still successfully drop from the search results within less than one minute.
What should have happened instead?: Obviously, draftspace redirects that don't have categories on them should not be showing up in incategory searches of those categories if they aren't actually in the categories. It's absolutely essential that I be able to do a clean incategory search on Living people -- with over one million articles in that category, searching for draft and userpages manually isn't a feasible alternative at all, so I need to be able to do an incategory search on that category without having it polluted by pages that aren't actually in the category. Removing draft and userpages from articlespace categories is an essential maintenance task that cannot be ignored, so I can't just stop scanning Living people for such pages entirely -- and while redoing the page move myself was a viable workaround when there were just one or two isolated instances, it isn't so feasible anymore when there are 10, 20 or 30 phantom redirects to deal with at the same time.,
Software version (skip for WMF-hosted wikis like Wikipedia):
Other information (browser name/version, screenshots, etc.):