I have run a lot of retrospectives and I have facilitated a lot of lists. What went well, what didn't, what I'll change. The lists are almost always accurate and almost never acted on. That is a follow-through problem, not a facilitation problem.
The retrospective format that works is shorter on diagnosis and longer on commitment. You do not need to spend an hour cataloging what went wrong. You need to spend most of the time on one or two things that are worth changing and who specifically is changing them by when.
The question I find most useful is not what would you do differently but what would you not start this way again. The second question gets at structural problems rather than execution problems. Execution problems fix themselves eventually. Structural ones repeat.
Every retro should end with three things: the one decision the team wishes had been made earlier, the one thing that went better than expected and why, and one named commitment with an owner and a date. Not a list. One. Lists get forgotten. One commitment with a name attached to it has a chance.
Read the retro notes from your last program before you kick off the next one. If the same items appear, you didn't change anything. That is useful information too, but only if you are honest about it.