The main __rec_upd_select loop chooses which update to write to disk. The first visible and writeable update is saved as the one to write. This generally works fine but it didn't handle prepared transactions committing at the same time, they would commit newest->oldest and in theory it could see a committed update and then write prepared updates out to disk. WT-6778 was created to handle that. And since then prepared update resolution has occurred oldest->newest.

This created a second issue WT-11186 where readers using ignore_prepare=true could see an intermediate update chain state as they would skip over the newest prepared update and arrive at older committed updates from the same prepared transaction.

If we allow the rec update select loop to remember a chosen update and then forget it later if it sees a subsequent prepare we could avoid requiring both WT-6778 and WT-11186. However initial investigations revealed that this would likely be a big change to that logic and it was determined to be of too great a risk during the release cycle. This ticket involves revisiting that decision and determining if there is a clean path forward.