I went through a bunch of testing on this. I set up a RPi with Bullseye and set up the queues I needed to test it with. I attempted to make sure there was package parity, in spite of having amd64 vs armhf. I can print from the Pi with color and duplex.
I completely tore down the CUPS printing on the original Bookworm installation (amd64) and rebuilt it from scratch. Again trying to ensure package parity with respect to printing and CUPS. Unfortunately, I had the same results. No duplex. I don't really have the resources to try setting up another amd64 box at the moment for further testing, but I made a rough comparison between the package versions. printer-driver-pxljr has version 1.4+repack0-6 on amd64 and 1.4+repack0-5 on armhf. I am fairly convinced this is not the problem, but there is definitely a problem elsewhere in CUPS. One other point of interest. I went to some effor to capture the raw printer files from both installations, specifically from /var/spool/cups/tmp. When printing the test page from the CUPS web interface, on Bullseye, there are two files, a "foomatic-<random>" file that is the PDF being printed and another one that 'file' says is "HP Printer Job Language data". The Job Language file is pretty small, 110K or so and in spite of it being a Pi v2, it printed very quickly. On Bookworm, there is only one file, also "HP Printer Job Language data". and it is quite large, about 11M. On the much more powerful amd64, it takes 30-40 seconds to spool the job. I don't know if the difference in spooling the document is due to the architecture (amd64 vs armhf) or the CUPS version. It could be ghostscript, which I believe is used for generating the output. On the Pi, it's 9.53.3~dfsg-7+deb11u6 vs 10.0.0~dfsg-11+deb12u3 on amd64.
