Few systems actually should need to depend on the clock tick matching actual elapsed seconds, and those who do depend on accurate elapsed time usually only do so short-term (while the program is executing) and don’t need to correlate that time with calendar dates and time-of-day. Most applications could very well live with an intermittently slowed-down time-of-day clock upon leap-second insertion, or a fast-forward upon leap-second removal, and use a different API when they’re interested in accurate elapsed time. But APIs have conflated those concerns, increasing the likelihood for something to grow when e.g. unix time diverges from accurate elapsed time.

I like to think that applications should be written under the assumption that the computer could be used by time-travellers, with the clock reflecting the respective changes to “local” time. That is, you would have calendar dates and wall-clock times reflecting the time travel, plus an elapsed-time clock reflecting the CPU’s subjective time. Then design your systems around that. As a consequence, they should also be immune to leap seconds and DST switches. But I guess that’s too much to ask. ;)