Yeah, it’s not an impossible to solve problem, rather I can’t think of a rather neat way to solve it in the current toolset. A Format with a bunch of different choices for each level (h2 Section, h3 Section, h4 Section…) to satisfy the various different large-book, small-book, paper/article structural schemes sounds very messy and confusing. Like you say, it feels like this Format would need instructions to explain why it has five tiles for Subsection that all look the same.
And the alternative is to fix the overloading problem by instead spamming a bunch of extra Formats into the list. Now you’ve got “Manuscript (Times) for Books with Parts”, “Manuscript (Times) for Articles”, and so on—multiply each bookish format by three.
Well yes and no, and I think that fact is something that would have to be part of an RTF solution as well. You can have the basic default linear assumption from the local compile group context, but I think you would also need the same thing Markdown has in the Title tab—a setting that allows for one to specifically target an h-level statically. That keeps Scrivener’s outline from being 100% slaved to the document structure, which remains one of its great advantages over outlines that aren’t, like Word’s.
But yeah, something like that makes the most sense to me, and what I was getting at by modelling structure from use rather than applying structure externally. Maybe even a “Hierarchical Heading” toggle in the style dropdown itself, which would cause the layout to produce h1, h2 or whatever depending on its contextual usage in the output. It’s a start, but there are still rough edges since RTF users have a limitation of needing to mix formatting with semantics intrinsically. I.e. how do you handle the ability to visually format parts differently from chapters, while making it possible for both parts and chapters to be “Heading 1”. I can think of some ideas, but nothing truly elegant.