Elements to include
When you're building a book, elements that you've included in the original document may need a little extra work to translate properly into the finished product. In addition, some elements that didn't seem important for a print publication may be more useful in an e-book.
Tables of contents
An e-book that isn't properly chaptered is difficult to navigate -- doubly so with devices where going to an arbitrary point in a book is not as easy as it should be. The Kindle, for instance, has no touch screen, so jumping around in a book without a table of contents is a chore.
This is most important if you want to set certain elements apart from the rest of the text -- for example, examples of code in a monospaced font. This isn't so much a formatting issue as it is a conversion issue, since font choices can sometimes get stripped out entirely during the conversion process, or not be supported at all on some target devices.
Be sure to try out at least two different font types in your documents -- a standard body-text font and a monospaced font -- to see how they render on different devices and in different book formats. Sometimes font declarations don't work at all: with the Kindle, for instance, you need to use the HTML <pre> tag in e-books to reliably show text in a monospaced font.
This can be a crucial issue for some books. You need to make sure any illustrations convert correctly depending on the system you're using. Exporting to HTML as an intermediate step helps here, since image references in HTML are honored pretty consistently throughout the conversion process.
Footnotes are typically translated into hyperlinks in e-books, but also run the risk of disappearing if the conversion process doesn't know how to honor them correctly. This is another reason why exporting to HTML as a first step is a good idea: if footnotes and endnotes render as properly hyperlinked elements in that step, they should remain accessible in the finished product, too.
Some languages -- Japanese, for instance -- use what is called "ruby markup" -- annotations that appear next to the text -- to indicate how certain things are pronounced. HTML supports ruby markup, but that doesn't mean it'll always render correctly in the converted e-book.
There are a number of other curious issues that can arise. For instance, if you have a document where outline headings (which typically indicate chapters) are auto-numbered, the numbering doesn't always survive the conversion process. One document I had automatically added "Chapter __:" to the beginning of each chapter, but once converted into an e-book the auto-numbering vanished.