The question shouldn’t be unravel the Jpg it should be time to abandon the jpg…in its old form anyway… 
https://jpegxl.info/
too many competing standards, for now: JpegXL, HEIF, WebP…
The jpeg is dead, long live the jpeg! 
The interoperability between jpg and jpegXL should make it something to adopt but that’s not enough to make it so…
Give it time. There are reference implementations for JPEG XL, but they are still maturing. There are lots of open issues (and PRs, to be fair) in the repo at the moment.
Darktable was an early adopter in a sense, and #10044 took a lot of work from dedicated people. It is understandable if browsers, which are very security-conscious these days (which is a good thing), are waiting for code to stabilize a bit.
JPEG is kind of old in the tooth now, but it is kind of amazing how long it served well.
For sure… I think it gets to be industry driven as well…no one want to be the Sony beta max tape that got bumped by shitty VHS tapes…now there is a reference that dates me
Edit seems to have some industry support
JPEG XL fans: Adobe, Facebook, Intel, even Google
Sneyers works at Cloudinary, an internet infrastructure company and JPEG XL backer, and has some important allies.
“I believe that JPEG XL is currently the best available codec for broad distribution and consumption of HDR still photos,” Eric Chan, a senior engineer at Adobe, said in an August comment before Google’s decision to scrap JPEG XL. “I’ve done several comparisons with AVIF and prefer JPEG XL because of its higher versatility and faster encode speed.”
Firefox supports jpegxl (with some settings modifications), but they still don’t work in my distro (Arch Linux) because the packagers did not compile it with the libraries enabled. 
Ok, I got jpgxl usable on my system by installing Firefox Nightly. I can create them with imagemagick (by converting other image formats). I can open them with darktable 4.2. I can edit them and export them with dt 4.2. And I can display them with Firefox Nightly.
Now, if only the rest of the world could see them.
Since they save bandwidth (up to 50%, compared to JPEG of equivalent quality), I am hoping that support will be widely available once the implementation matures. Bandwidth is cheap and end users are (usually) not constrained, but it adds up. HTML’s <picture> tag makes it easy to serve JPEG as a fallback.
Same info on a video https://www.youtube.com/watch?v=Q2aEzeMDHMA&ab_channel=Computerphile