The Answer Depends on What Else Is in the Room
A package conflict prompt asks the same question twice. Answer yes, it fails. Answer no, it fails. Same prompt, same two options, same failure both times, because the failure was never really about the prompt.
Run the same install by itself, outside the big transaction, and the identical question resolves on the first try. Nothing about the conflict changed. The package didn't get easier to reason about. What changed is everything else that was in the room with it.
A constraint solver doesn't answer a question in isolation even when it looks like it's asking you one question at a time. It's holding a whole graph, and your yes or no has to be consistent with every other edge in that graph simultaneously. Bundle four hundred packages into one transaction and the conflict you're staring at is now entangled with library versions and dependency chains that have nothing to do with it on the surface, but everything to do with it in the solve. The prompt is a local view of a decision that's actually global. Somewhere in that batch is a dependency that only makes sense if the conflict resolves one way, and another that only makes sense if it resolves the other way, and the solver can't tell you that directly. It can only fail on the same yes/no forever, because there is no answer inside that scope. Shrink the scope and the contradiction goes with it.
This is the part that's easy to misdiagnose as the question being bad or the tool being stupid. It's neither. The question is well formed, it has a correct answer, that answer is just not fixed by the question's content, it's fixed by the size of the problem the question got dropped into. A conflict that's trivially resolvable at N=1 can be genuinely unsatisfiable at N=400, not because the underlying facts changed but because more constraints came along for the ride and some of them are incompatible with each other in a way that routes through your yes/no as the visible symptom.
The fix people reach for first is usually to argue harder with the prompt. Try yes again. Try no again, more carefully. Read the error output for a clue about which answer it secretly wants. None of that works, because the prompt isn't hiding information, it's an accurate readout of an unsolvable local state. The actual fix is to change what's in the solve. Pull the one package out, ask the narrower question, let the solver work with a graph small enough that a contradiction elsewhere can't route through this decision. Same conflict, same answer, but now there's nothing else in the room to make that answer inconsistent.
Once you see this shape you notice it outside package managers. Any yes/no that runs through a shared solver, a scheduler, a merge, a build system resolving a dependency graph, a database planner choosing a join order, carries the same property: the question and the answer are not the same object. The answer is a property of the batch. Two people can ask what looks like an identical question and get different, both-correct answers, because one of them asked it alone and one asked it bundled with three hundred and ninety-nine other things that happened to need the opposite.
So when a well-defined yes/no stalls somewhere it should obviously resolve, the useful move isn't to re-litigate the question. It's to ask what else is currently in the solve with it, and whether it needs to be.