[ElMiko]

Thanks for those thoughts, @Turtle91.

I think that part of the reason I'm trying to confirm if <em> is actually implemented semantically in current/mass-market TTS is that if it isn't, I'd expect their eventual implementation to also allow users to select semantic preferences based on nominally visual tags (e.g. <i> and <b>). Given the existing catalogue of reflowable ebooks that do not use the semantic tags , it would be surprising if these programs didn't account for that possibility. "A gajillion ebooks use <i> (or spans) instead of <em>. I've decided I'm finally going to incorporate semantic rendering into my TTS program. But I'm not going to offer users the option to apply semantic rendering to anything but <strong> and <em> despite knowing that these have not been consistently implemented." Perhaps (no, DEFINITELY) I've been too spoiled by developers like those of Sigil and Calibre who are constantly adding almost insanely granular modifications to their programs to accomodate users' idiosyncracies, but there you have it.

If however, the majority—or a significant plurality—of these TTS programs (particularly those used in ebook platforms) already incorporate semantic differentiation, then a standard has already been practically established for those kinds programs that doesn't accomodated semantic recognition of visual coding. It would then make a lot more sense to change my workflow and to modify past projects.

In either case, I fully grant that your point about the possibility of EU-like regulation is a strong argument in favor of preemtively switching to <em> where appropriate, though.