Ah yes, the damn POSIX epoch specifies time since in Epoch in UTC. I thought it was just "seconds since epoch". :(
Anyway, the question remains: exactly who needs to have the leap-second occur as an inserted second, rather than a spaced out smear?
People who need precise control/responses: They definitely don't want it, they need accurate relative time.
People who need 1±0.1 second accuracy to the global reference of UTC: well, that must be because they need to compare time across systems. In which case, they need some *other* system to synchronise time across those systems, such as NTP. If those systems are within one organisation, they can use NTP to do the slew in a relatively co-ordinated fashion.
So whose left? It seems to me that it must be organisations who wish to compare time to ±0.1s accuracy across systems distributed over multiple organisations, who do not normally work closely enough together that they can arrange to synchronise to anything other than UTC.
So how many such organisations exist with those kinds of requirements? What is the application? Is it even realistic to expect ±0.1s accuracy in timestamps at such scales?
Why hold the reliability of our software hostage to requirements that few likely need or care about? Would it be possible to punt to userspace, and have NTP handle the method, through an interface that allows the kernel to be agnostic about it? Wouldn't that be much much better for pretty much everyone? (Don't you need to run NTP in the first place in order to get the leap-second?).