This is a known bug that was unfortunately accidentally filed as middle priority when it should have been high.
The problem, incidentally, seems to be confined purely to paragraph styles that also override character attributes. Those that do not (most of the stock style settings) should not see the loss of direct formatting in paragraphs.
To clear up some potential misconceptions:
-
You are absolutely intended to be able to use styles in the editor! Any video tutorial or book that told you otherwise is feeding you bad information that makes no logical sense. If you were not meant to use styles in the editor, we wouldn’t have made that feature or the host of support features surrounding it—like for instance why would there be a compile setting that can change the name of an editor style on output if you weren’t meant to use editor styles and compile styles to output?! I’m not venting this at you to be clear, it just boggles my mind that someone would think to sit down and make a video, or write a book saying you should use a feature at all. Sorry you got lead down a wrong path on that one.
-
The only possibly confusing exception to that is that Scrivener is not a program that requires you to use styles, and works better without wall-to-wall styling. It can be used that way, to be perfectly clear. But the use of styles is designed to force editor formatting. It is a way of exerting control where needed. So you can see a powerful tool like that is immediately at odds with the concept of a compiler that is meant to freely reformat text. Those that use body styles everywhere run into a wall when trying to use Manuscript-Times.
But you can, and for the same reason you can use Block Quote with Impact 24pt font while writing, and Manuscript-Times reformats it correctly—you just have to do a whole lot more learning and configuration to work that way. That means it makes more sense to give the up-front advice to not use body text styles, and save styles purely for exceptionally formatted text, as described in §17.1, Think Different.
-
Styles should translate into the compiled document—again we would not have a styles pane in the compiler if styles were not meant to output. There wouldn’t be an optional setting in that pane that excluded styles from the output, if styles were always excluded.
I cannot reproduce that condition myself. I would try simplifying your conditions to see where it breaks, starting perhaps from a blank project test that has one lorem ipsum paragraph with one word styled to Emphasis, compiled to RTF (because everything else involves third-party conversion utilities, which increases complexity and contaminates the test).
To circle back around to the top: the main issue here is a bug that nukes formatting if the styled text has character attributes applied to it. It basically seems to be taking the style and reapplying it to the paragraph during compile, which has the effect of normalising the text in the paragraph to what is styled.
If you can get away with not having character attributes in the editor style, then that is your workaround. Consider that your compile settings can be set up to have a matching style that further transforms the formatting and that approach does not seem to trigger this bug.