On the matter of achieving more than one table design in an ebook, the best way to accomplish that would be to get a classed div around the tables that need special formatting. There are several ways you could go about doing that, but probably the simplest method is to put the div around the table itself in the editor:
- Create a paragraph style in your project and name it: “Raw HTML Block”, just like that. There is a style in the stock Ebook compile format that is already set up by that name that will do what we want: pass anything you type into such styled text directly into the ePub.
- Now just type in
<div class="plain-table">(or whatever), onto a line above the table, and</div>on a line below the table, making sure to apply this style to both of those lines.
The formatting is entirely arbitrary. I made it very obvious for the sake of demonstration, but for actual usage you might want to use a light grey text colour to diminish the appearance in the text flow.
The other method is probably easier to demonstrate by example, so I’ve included the above, and the Section Layout approach, in this test project.
table_designs.zip (43.1 KB)
If you compile that with the given settings, you’ll find one of the tables lacks any adornment and cosmetically treats all rows as data. The second table acts like a vanilla table. The secret ingredient here is in the “Plain Table” section layout. If you examine the Settings tab for that, you’ll find we are giving this section a CSS class of ‘plain-table’. It’s generating the classed div for you, in other words, keeping the mechanics out of the editor.
You might note I’m also using the <$title> placeholder to make the heading of the table in the binder its caption. This is a technique I use, and it makes it easier to create a document template out of a table setup, so you can just drop in a boilerplate, name it, and fill in the data. Having the caption as the binder title is almost always the best way to identify a table in a list anyway.
There are other ways you could go about this, to be clear, these are two of them. One could for example cut down on the raw HTML by using Replacements to generate the HTML itself, and only type something like [start: plain table] and [end: plain table] into the text editor itself, but I figured a more straight forward example would be better, so it is easier to see what is going on.
The section layout method is closer to what I would use myself, as I’m a heavy user of Scrivener’s outlining potential. I prefer having figures, tables and even other formatting elements in their own blocks in the binder, so that I can easily search by them, build lists of them, and give them special output capabilities in the compiler.
Thanks! This works, but I’m very reluctant to introduce adhoc fixes to something the compiler should get right…
To close on this, I’m perhaps from another universe of expectations. 
To me this all seems like the sort of things one does if they want more advanced designs. The automation (the compiler in this case) should handle the 99% without much tinkering, but if you want more this is how to tinker, and software that lets you do that is infinitely more interesting to me than software that doesn’t let you tinker and just does what it thinks is best with hard code and template output.