I am able to reproduce this. It is not a new problem. I am able to reproduce this in a pre-logging-changes tree as well, once I understood the circumstances and forced them to be the same on the old tree.
What is happening is that we perform a full checkpoint at, say, LSN 1,N. The metadata and the turtle file both have 1,N in them. We write the actual checkpoint record containing 1,N at 1,N+1. The record at N+1 happens to be the last record that will go into log file 1. When the connection closes, we force a checkpoint record to be written and that gets written at 2,128. That updates logging's internal checkpoint LSN to 2,128. Between the time of writing that clean close checkpoint record and shutting down the logging subsystem, the archive thread runs and removes log file 1. All metadata entries and the turtle file have checkpoint LSNs in log file 1 and when we reopen and run recovery starting from 1,N it doesn't exist and we get the error.
I can see several different ways to fix this and am considering which one is the best.