JPEG-XL as Content-Encoding?

Hey HTTPers!

I was reviewing an intent to add JPEG-XL as a content-encoding
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZPrBjS75%3D%2B%3DSexFkJ7ewkBXDOF6FhkpwQYBeWn6sT57n1-_w%40mail.gmail.com?utm_medium=email&utm_source=footer>
for JPEG images, and thought I'd get some feedback from y'all regarding it.

The team behind JPEG-XL think that since it can be used to
seamlessly transform JPEGs, it might be interesting to enable that
transformation to happen at the HTTP layer and get ~20% smaller images
*automagically*, as compression would be done by supporting web servers and
image compression providers.

I'm slightly more skeptical about how automatic that would be, and find it
somewhat strange to have image-specific content-encoding, while other image
formats are served as separate mime types and negotiated with `Accept`.

So, a few questions:

   - Would it make sense to have an image specific content-encoding?
   - Are web servers more likely to perform JPEG=>JPXL transformations if
   JPXL is a content encoding, compared to browser support for it as an image
   format?
      - Note that those transformations are CPU heavy, so will need to be
      cached, or done at "build" time.
   - Same question for CDNs
   - Finally for CDNs who already transform images - have you run into
   compatibility issues coming from web content manipulating raw image bytes
   directly, and failing to do that post-transformation?

I'd highly appreciate y'all's opinions!

Cheers :)
Yoav