My claim that it was redundant was based on my (admittedly, mostly on macOS) testing; plus my read of these docs, which seem to imply that the built-in default for library installs is lib.

Reading deeper into the GNUInstallDirs docs, I'm guessing the problem is that lib isn't always the default value - AlmaLinux 8/Centos 7 will be using lib64 as a default value. If the rest of Pillow's build system is relying on a predictable /lib suffix, then that would explain the problem you've observed, and why I didn't see any difference (most of my testing has been on macOS).

Regardless - I don't have any objection to the CMAKE_INSTALL_LIBDIR change being reverted; my only question would be whether the same option should be added to the other CMAKE usages (openjpeg and blosc), for exactly the same reason.

If you think that the default behaviour of libjpeg-turbo is correct, and Pillow should be updated to handle it, that's fine - I was just saying that this change isn't without consequence, and wanted to make sure there was some motivation behind it.

My motivation was that it appeared to be redundant - and on macOS, it is. However, you've demonstrated it isn't on at least some Linuxes.

I'm currently elbow deep in Pillow's buildsystem; based on what I've seen so far, I'm sure there could be a fix in Pillow's build system - specifically, configuring BUILD_PREFIX to use lib64, rather than defaulting to lib. However the alternate fix is to revert the CMAKE_INSTALL_LIBDIR change as you've suggested - and that approach means there's no backwards incompatibility for any existing users.

However, if the fix is a revert, I'm arguing that the fix is also needed to the other CMAKE uses for consistency.

I think Pillow is a good use case, so maybe we can explore getting Pillow + multibuild working on a branch of both, and then resubmit needed fixes.

the fix is also needed to the other CMAKE uses for consistency

We have not so far received issues about CMAKE_INSTALL_LIBDIR, so I am inclined to merge this as-is, in the vein of "if it is not broken, don't touch".

We have not so far received issues about CMAKE_INSTALL_LIBDIR, so I am inclined to merge this as-is, in the vein of "if it is not broken, don't touch".

That sounds entirely reasonable to me. It's not impacting my usage, I was just flagging a potential inconsistency. If that inconsistency isn't proving a problem for others, I don't see a problem waiting until it does.