Let's just get this out of the way and hope the C++ port fixes this "properly".
I'd like to better understand what do we hope to see out of the C++ fix.
My patches in bug 1503657 do not skip the sanitization, just like the JS implementation doesn't skip it today. If we want to, Kris helped me craft a way to make us skip it, but I believe that we'd have to hold a conversation with the security team about it.
The patch that Gijs wrote seems pretty straightforward and could be ported to C++ as well, but I'm not sure how it'll handle localization in the long run.
If I understand correctly, the patch allows named element matching between source and translation, so the following code would work:
key0 = This is an <img data-l10n-name="picture"/> image.
This would work with Gijs patch in rev. 2, and with my current proposal POC patches in rev. 3 of DOMOverlays, but depending on the final decision with rev. 3 it may or may not work.
We'd need to commit to reusing the matched element from the source in the translation. Code-wide, that's easy. Spec-wise, I don't know. Unfortunately, this seems to fall into the gray area between Fluent design work (L10n Drivers group), localization management for Firefox (L10n Drivers group), and Fluent in Gecko bindings (Browser Architecture group).
I'm comfortable taking the responsibility for the last and in result accepting the patch into the tree and committing to maintain the quirk of ftl:img==xul:image, but since the result may affect DOMOverlays rev. 3, I'd prefer to get consensus with whoever will lead DOMOverlays rev. 3 spec work, and I'm not sure if that'll be me :(
Axel - do you have any concerns about it in the context of rev. 3, or just the sanitization?