Robin2:
I think what has been confusing me (maybe still does) is your phrase "when there is any latency between the timed condition becoming true, and the code to detect that executing". I believe that by "saving" millis() at the start of each iteration of loop() it doesn't matter when the code actually gets around to executing the event. And the timing of the subsequent event is not linked to the actual time of execution of the previous event. Instead it is linked to the value of millis() at the time the loop() began its iteration.
I think you have understood the problem correctly.
The scope for latency within a specific sketch can be affected by the placement of the call to millis() relative to the call checking whether the time has elapsed, and by how frequently the loop executes, but the latency can never be reduced to zero.
This is a problem that has varying severity and varying impact. Arguably, in many cases it can be ignored. However, the issue of how to control multiple things independently, including controlling independently timed things, crops up so frequently, and is so fundamentally important for newcomers to understand, that I think having a really good example of 'best practice', together with an explanation of why that is the best practice, would be extremely useful. It's a great shame, and a lost opportunity, that the 'blink without delay' example is so poorly explained and so mediocre in implementation. This is why I'm so keen for you to develop your example to the point where it really does represent best practice, and not just 'good enough for simple examples'.