This is a bug in epubcheck as far as I can tell. I exchanged comments with them as well.
See my post here and their replies.
https://github.com/w3c/epub-specs/is...ent-1496140289
The issue is that epubcheck now wants *all* xhtml linear="no" in the spine to have a direct link to that file from some other resource in the spine. This was seemingly done to prevent unseeable spine content in all epub readers.
That requirement is fine for normal xhtml files but NOT the nav document itself. Any epub3 e-reader can always access the nav itself, so it should be exempt from this new requirement by epubcheck.
There are only 3 workarounds:
1. remove the nav completely from the spine, and edit the nav code to remove its own internal link to its toc in its landmarks section as only files listed in the spine can be linked to, due to epubcheck. But removing it from the spine means no easy drag and drop reordering in Sigil.
2. create the css necessary and link it to the nav so that the nav appears just like a desired xhtml toc in appearance and remove the linear="no" associated with the nav so that the nav itself functions like a directly linked user xhtml toc file (ie it plays 2 roles - both machinereadable nav and user toc). But not everyone wants a user xhtml toc.
3. leave it as is, but create a link to the nav.xhtml from some other file such as a user toc.xhtml. This is the solution I use until epubcheck gets fixed.
None of these workarounds are ideal. The bug that requires a link to the nav.xhtml from some other spine resource just because it has linear="no" in the spine should really be fixed in epubcheck.
Sigil and epub3-itizer use linear="no" on the nav entry in the spine as that used to be the documented best practice for epub3 during 3.0, 3.1, and 3.2 specs, and earlier epubcheck versions.
I am still hoping someone from epubcheck will come to their senses and exempt a properly specified nav from having to meet this new additional requirement.