How in the world did astronomers & their software developers manage to push off onto the rest of the software world (and society at large) the atrocious concept of leap seconds.
Not astronomers but naval navigators. UTC is direct descendant of time signals broadcast by naval observatories as a companion for their naval almanacs. It ended up as general civil time pretty much because it was there and there wasn't much competition around.
Besides when UTC was standardized and adopted in the sixties, software wasn't really much of a concern
UT1 might not work for engineering applications with tight tolerances, as the length of a UT1 second varies.
Personally, in my non-expert opinion, we should stop adding or subtracting leap seconds from UTC (that is, UTC would thereafter be at a constant offset from TAI), and leap seconds would instead be added to the timezone DB. That way local time (like Aug 14 2022 xx:53) would still retain the familiarity with 12:00 being noon, at least at some point in each timezone, but calculations with UTC seconds would not need to bother with leap seconds.
If people don't like leap seconds, there is no need to redefine UTC; they can just use TAI today. That gives them the additional advantage of not having to handle leap seconds in the past, because software that handles historical UTC timestamps will always need to know about the leap seconds that have already happened.
All our computer and protocol infrastructure is setup to handle and distribute UTC. Everything else you talk to is speaking UTC.
Trying to use TAI in a UTC world doesn't save you from dealing with leapseconds in the slightest: You get all the leapsecond induced problems just obtaining TAI from your UTC feeds and them you get them again at every boundary where you need to communicate with something else that is using UTC.
At least if you use UTC across the board you'll only fail around leap seconds (or false leap seconds created by issues in leapsecond distribution infrastructure). If you attempt to use TAI you'll get those failures plus many extra ways to fail.
> that handles historical UTC timestamps will always need to know about the leap seconds that have already happened
That's static data that can be hardcoded and tested, massively easier and safer than events which are being inserted (or accidentally failed to be inserted) in real time.
The big problems with leapseconds arise because of the realtime discontinuity and because the offset function changes in unpredictable ways.
In many applications there just isn't any old dates to begin with. E.g. in my code that points my telescopes (and determines where they're pointed from the encoders) I have a pile of nonsense to hopefully handle leapseconds, which may or may not actually work right when one happens as its really hard to test how other software will behave. But the same software never needs to handle times more than a day (or a few days) in the past.
If leap seconds stopped being issued bugs in software impacting billions of people would just vanish. Not every bug-- some things might also mishandle historical leap seconds, but most of the issues come from realtime bugs. If you go too far back times wouldn't have been known to 1 second in any case, so bugs with historical data would mostly be in the form of things breaking due to inconsistent time difference calculations.
But most operating systems already have their own mechanism to update their timezone database. This is not a problem. Shifting timezones by 15 minutes every few thousand years would work with current software.
All we need to do is to agree that UTC will have no more leap seconds.
Leap seconds are problematic for astronomers whom either are doing things that don't care (e.g. 1 star calibrated against the sky, that calibration approximately incorporates whatever difference between UT1 and their local clock exists) or where they do care they have to back the leap seconds out in order to apply a more accurate model of UT1.
It's actually quite tricky to back out leap seconds accurately because the underlying time will be discontinuous for you and you can't reliably tell when leap seconds have or haven't been applied... you might even, without knowing it, be being fed leap-smeared time which could evenmake your sidereal tracking wrong and can't be backed out because different smearers do it differently. Because leapseconds they're infrequent, you also don't get many live fire tests.
I'm aware of multiple observatories that just shut down operations across leap seconds. The significant amount of work to handle leapseconds correctly and be confident you're correct isn't justified vs taking some downtime.
Besides when UTC was standardized and adopted in the sixties, software wasn't really much of a concern