Pushing back a bit on the “mistakes of youth” thought, there actually is a real world case (again from medical devices, you would be surprised at what hoops you must pass through for FDA approvals) for this kind of PID bouncing (although definitely not in the way that @rusakov2 describes, no crazy whack a mole PID bouncing!)
With medical devices, and also for devices that have potential for causing human harm like robotic control mechanisms (which need to be approved by OSHA, another big briar patch) you need to be able to guarantee three clearly distinct operating modes: pre-program, normal operating and “safe” mode.
Pre-program means “this thing has no idea what it’s supposed to be doing or doesn’t have the right info for the task at hand” so the only thing that is allowed to be able to communicate with it is a programmer
Normal operating means “this thing knows what it is supposed to do, and is operating within accepted parameters, and is checking those parameters” so it is in a state where it can actually “do” that important something (monitor IV pump status, control the robotic can sorting, launch the missiles, etc.)
“Safe” mode means “something went wrong with this thing” so the only thing that is allowed is to be able to communicate with a diagnostics application. Note that this is not the same as pre-programmed; you have to be able to diagnose the fault first … the pump sensor failed, the puffer video camera failed, the hydrazine pump for the missiles failed
The only real way to accomplish these items are by having the device firmware change PID’s, one PID for each state, which will ensure that only the appropriate client can access the device … that’s three device drivers in days past (as @rusakov2 mentioned) and either three firmware images within the device or in the case of programmable device firmware three firmware loads.
These days I can accomplish this by having a single driver contain the firmware for each mode, and monitor for each PID; one driver, three operating modes. When the device is in the pre-program state the driver can push the firmware for the programmer application based on the PID, when the device resets and uses the normal mode PID the driver again loads up the firmware for the operating client, when the device goes into safe mode again same thing, load up the safe mode firmware … that’s one device driver, it just contains three firmware images
Why contain the images and not just read from files? Security, you need to be able to verify the firmware can never change. Even if you were to sign the firmware there is still the danger of an “old” buggy (signed) firmware file being copied over the “new” one or the firmware simply being deleted so by encapsulating the firmware into the driver that checkbox is addressed …