AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go.
Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels.
With that in mind I'd actually prefer if those were treated as separate file-formats with distinct file-extensions (backwards-compatible jpeg->jxls vs pure-jxl). The former could be trivially handled with automated tools, but the latter can't.
Well, sure, but wasn’t that the use case we were discussing?
I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)