I wrote:
2. This approach puts it on individual tzdb distributors to decide which of these two options to choose. Some will choose differently than others, meaning we'll now have two received versions of tzdb, which is as bad as a fork from the perspective of end users.
(It was argued that we already have problem #2 because some distributors already use backzone. AFAICT that's only a small minority though. It'd likely become a much bigger issue.)
To put some detail on that claim ... I ran around and checked systems I had handy to see whether the vendor-provided tzdb includes backzone. I checked this by seeing whether Africa/Timbuktu contained different data from Africa/Abidjan, which hasn't been true since 2014f unless you built with backzone. (Some of the system images I checked are a year or two old, but it seems unlikely that any vendors would have changed their policies recently.) Of Red Hat (both Fedora and RHEL) Debian macOS FreeBSD OpenBSD NetBSD not one is building with backzone. I think it's reasonably safe to assert that the current population of backzone users is negligible. (Of course, Windows would be the elephant in the room here, but last I heard Windows uses their own timezone database not tzdb.) regards, tom lane