Regarding brunsli vs JPEG XL "lossless": yes, JXL fared better there, but then again did not have the requirement of reproducing the bit-exact JPEG back on demand. So (as far as I understood) JPEG XL in q=100 will go back to the pixel data and run the the full JPEG XL coder on it (with no quantization to avoid loss), while JPEG XL in reversible "bg" mode[1]/brunsli will only decode back to the coeffs (so there is no loss at all) and then use their superior lossless (brunsli) coding to store these coeffs more efficiently along with some metadata to allow reconstructing the original file on demand.

I could be wrong, I only skimmed the docs and code; when I was quite tired.

[1] JXL has a "bg" mode too that is reversible to the original JPEGs, but that's currently not exposed by the cjpegxl tool. But I saw in in their benchmark tool, and there it produced essentially the same size files than plain brunsli tool did, probably because it's essentially just the brunsli tool.

Yes, I believe that's right. JPEG XL is able to compress JPEGs in a way that is pixel for pixel identical to the output of a JPEG decoder, but can't be reversed into a bit exact copy of the original JPEG.

Just one clarification about this: As stated before in these comments, JPEG XL includes brunsli, so JPEG XL allows for byte exact transport of the original JPEG file (with -22 % in size). This can be practical for example for file system replication or for long term storage of a lot of original JPEGs. The other, non-brunsli JPEG XL modes can do pixel exact, but byte exact can be more appealing for some use cases.