I don't remember ever hearing sandwich timers described. Affer I read about PTTES the idea of finding out how well they could be made to work on the PICAXE chips fascinated me and I am very pleased with the result.
I have never heard them described as such but we are doing similar when we use PULSOUT and a PAUSEUS to bit-bang out a Servo Loop. The difference is we don't use timers, just have a wait of 20ms, minus the pulse period, minus whatever overhead we think we have. Same too when we throw in a PAUSE 1000 minus something at the end of a loop to get output about every second.
Starting a timer, doing something, then waiting for that timer to timeout gives far more accurate timing. The neat trick with your solution is that 'wait for timeout' is just DOZE, set-up is a simple SETTIMER. I would have poked and peeked timers or their overflowed flags and this is a lot simpler than that.
Most programs are a single task in a single loop , where one often wants things to have repeatable timing, which I suppose is a sandwich with just one slice of bread. But there are cases where there are more steps and each needs to start at certain time marks and your implementation does make that easy to have.
It also means 'jittery, but best we can get' fixed PAUSE at the end of loops where one cannot be bothered to work out how long a task may actually take or handle variance, can be made to have much better timing accuracy with just two commands.
What impressed me is that it's such a simple solution, and well done in figuring it out - Seems you can teach an old dog new tricks.
If someone wanted to schedule a task every 5s using sandwich timer code that generates a hardware interrupt every 250ms, like in your example, then the code for their task must always complete in well under 250ms.
Yes, exceed that and one won't get the interrupt until 250ms after the last which has been ignored.
I was thinking it might be possible to peek the timer, at its end or while running, to tell when it had missed an interrupt if a task took say 150ms some times, 350ms others. But that makes things more complicated.
The pragmatic approach would be to split any task which might exceed 250ms into smaller parts which won't.