I was testing out some fresh code concepts and noticed that with a fixed update step, variable render step with interpolation, I believe the frames end up not having a perfectly consistent time between each other.

This is because whatever time the update takes, is not spent rendering, meaning there is a larger gap between those frames. e.g. picking a 25Hz update rate and assuming both update and render take 10ms, for some nice easy numbers.

When the update happens it causes extra time between two frames completing. This can also be seen in the delta time fractions for interpolation, if the update is said to happen at “0%”, then the first render starts at 25% (at 10ms since the start of the update in the example), then 50% (20ms), 75% (30ms), but then 100% (40ms) never happens, that is the next update and will be 25% (50ms), so a 50% or 20ms “jump”.

Now visually I never noticed any lack of smoothness (at least at a high enough FPS it should be smooth), but then I never really noticed a difference in ultra-high framerates and monitor refresh for FPS, so I wonder if that is just me?
Or did I screw up my understanding of the loop (based on https://gafferongames.com/post/fix_your_timestep/)? Or is this just expected and really no one can notice this?

With multi-threading I believe this is a non-issue as the render loop won;t be getting interrupted (although probably something different), but plenty of games are single threaded.

There's nothing wrong with your understanding, in such a single-threaded architecture the “update + render" frame is going to take longer then a render frame alone. But at a high enough framerate with good interpolation, it's highly plausible you wouldn't notice. Consider also that only every 4th frame in your example takes longer, so the average frametime is 12.5ms (80 FPS), only a bit longer than the 10ms frames that could be achieved in the ideal multi-threaded scenario.

So I spent some time playing around with intentional delays and didn't really get anything that felt conclusive. I also wrote a multi-threaded version of the same thing to see if would have a perceivable difference and didn't really notice one, even the one I expected since on reflection there was a timing flaw in my update→render state transfer logic.

Maybe just because an objects movement has a consistent “average speed” it looks OK, even if frame-to-frame pixel movement isn't perfect. It's kinda strange because say 30fps is noticeably “less smooth” but a slightly inconsistent frame by frame move speed doesn't stand out to me as a specific thing still.

The Android thing looked interesting, but I couldn't see exactly how that can be applied in general. There is VK_GOOGLE_display_timing but that seems to have limited support and just not exist in OGL, D3D11, etc. as far as I could find? And even less sure if a significant number of games use such a thing?