> the 32-bit to 64-bit transition

Lzma is from 2010. Amd64 became mainstream in the mid 2000s.

> removal of pre-C89 support

Ibid. Also, at the library API level, c89 compatible code is still pretty familiar to c99 and later.

> new architectures like RISC-V

Shouldn't matter for portable C code?

> the increasing amount of cores and a slowdown in the increase of per-core speed,

Iirc parallelism was already a focus of this library in the 2010s, I don't think it really needs a lot of work in that area.

Actually, the new architectures are a big source of concerns. As a maintainer of a large open source project, I often received pull requests for CPU architectures that I never had a chance to touch. Therefore I cannot build the code, cannot run the tests, and do not understand most of the code. C/C++ themselves are portable, but libs like xz needs to beat the other competitors on performance, which means you may need to use model specific SIMD instructions, query CPU cache size and topology, work at very low level. These code are not portable. When people add these code, they often need to add some tests, or disable some existing tests conditionally, or tweak the build scripts. So they are all risks.

No matter how smart you are, you cannot forecast the future. Now many CPUs have a heterogeneous configuration, which means they have big cores and little cores. But do all the cores have the same capabilities? Is possible that a CPU instruction only available on some of the CPU cores? What does it mean for a multithreaded application? Would it be possible that 64-bit CPUs may drop the support for 32-bit at hardware level? Tens years ago you cannot predict what's going to happen today.

Windows has a large compatibility layer, which allows you running old code on the latest hardware and latest Windows. It needs quite a lot efforts. Many applications would crash without the compatibility patches.

I am a former MS employee, I used to read the compatibility patches when I was bored at the office.

Anyway, liblzma does not "need" to outperform any "competition". If someone wants to work on some performance optimization, it's completely fair to fork. Look at how many performance oriented forks there are of libjpeg. The vanilla libjpeg still works.

and then that fork becomes more performant or feature rich or secure or (etc), and it becomes preferred over the original code base, and all distributions switch to it, and we're back at square one.

The vanilla python works fine but conda is definitely more popular among data scientists.