I wonder from a technical perspective how many of the bad developer experiences like this are arising almost entirely from a lack of continuity between app revi

I wonder from a technical perspective how many of the bad developer experiences like this are arising almost entirely from a lack of continuity between app reviews. A number of commenters have pointed out their experiences in resubmitting the same (unchanged) app and getting s different outcome. Similarly, in this case, it sounds like an issue came up in the recent review which had previously been addressed 3 years prior. I wonder if improved continuity would let Apple offer higher quality reviewing and a better developer experience? It seems like many of the complaints of arbitrary decisions could be coming about from a lack of continuity in one app's review. Clearly at Apple scale, they aren't likely to have the same human reviewing the app repeatedly for years on end, but I wonder if there's a low-difficulty patch to this process to get better communication and continuity between reviewers, and more context in the communication with developers. I don't have experience with this review process in particular, but often these processes favour "ticket" style ways of working - developer caries out an event which results in an item entering a queue, and items from the queue get served by the first available server (aka reviewer). Given the review process takes time, I wonder if it would be more productive for the review to appear as more of a conversation? Perhaps even semi-synchronous or asynchronish? At the reviewing side there must be a fairly significant amount of mental context switching taking place between apps, re-submissions etc. Maybe Apple is simply expecting too many high quality context switches per individual per shift, resulting in mistakes in reviews, but isn't doing enough oversight to spot mistakes and optimise to reduce them? Is there any incentive to drive them to improve their mistake rate?