That’s quite the assumption to make considering 1) this “feature”/bug did not exist before, and 2) at least 106 people disagree that exporting to PDF looks fine, and that 3) the people in the Print thread fundamentally agree that Exporting to PDF should not look the same as for print.
Plus, I’m a theme dev, and the person who actually pushed on re: the CSSClass bug in Export to PDF which you kept rebuffing others that it wasn’t a bug at all when it actually was (second link). In that sense I probably do have more technical knowledge than you in terms of exporting to PDF and of CSS, and I can confidently tell you that like 4 years ago, @media print does absolutely nothing to resolve this since what we see isn’t created via @media print, but via what is set via a separate .print class div and everything below that, which inherits everything from the body (including the `.theme-light class) and which is also the reason why the cssclass bit was a bug in the first place. I believe Liam can concur this is the process where the Export to PDF result is generated from.
I am happy to leave this as it is as I have my own workarounds to exporting to PDF (by setting a breakpoint and manually dropping the theme-light classes) but considering that 1) this intentional feature did not exist for quite a few years, 2) exporting to PDF is for print is an assumption that does not hold (then why would we have the print FR and so many people complaining?), and 3) it pretty much goes against the ethos/manifesto that Obsidian should be malleable by creating a new bug that forces everyone to do the same thing (furthermore, one based on an assumption that does not hold), I do hope that this can be reconsidered.