If I'm reading that correct, the only way this should cause problems is if either your spine contains things that shouldn't be in there or your TOC is missing things that should be in it.
The spine should contain all of the main content, in linear reading order, and nothing else. For example, you might leave out end notes if they're in a separate file, or pages that just contain a larger version of a linked image, or other content that isn't part of the primary reading flow. Otherwise, it should be a complete view of what the book should look like if you were going to print it, in order, with no nesting.
However, it is worth noting that the spine contains exactly one entry per physical file, with no access to parts of a multipart file (a chapter with sections, for example). Its purpose is to tell the reader the order in which to glue the files together.
The TOC, in turn, provides the ability to structure the contents of the spine in a nested fashion. For example, you might nest chapters inside parts. The spine would contain the part page, followed by the first chapter in the part; the TOC would contain the part page, with all
navPoint tag for each chapter in the part nested inside the part's
navPoint tag.
Additionally, if you have sections within your chapter files (e.g. with named anchors before section headings), you can add these in the NCX as separate
navPoint entries using fragment IDs (e.g.
foo.xhtml#jumptarget). Caveat: top-level
navPoint entries should not have fragment IDs for maximum compatibility.
So the TOC should always contain either the exact same entries as the spine or a superset of the entries in the spine (if you're adding links to sections within files), and should never contain a subset of the spine entries. If there are entries in the spine that aren't in the TOC, either the spine is wrong or the TOC is wrong.
