There are actually two completely separate issues here: the first was well-deduced by sero, and is a general issue; the second, reported by Ioa is a macOS bug specific to 10.12. I’ve fixed both for 3.0.3, but in case you are interested in the details:
1. Not all of the selection gets highlighted
Sero’s gess was spot-on here. When Scrivener toggles highlights (or strike-throughs) on or off in a PDF view, it has to apply or remove the rectangle for each line separately. When adding highlights, it also removes any existing highlights from the selection (otherwise you could end up putting a pink highlight over a green highlight.) The only way it can detect existing highlights, though, is by going through all highlights on the page and checking to see if any of their bounding rectangles intersect with the current selection rectangle. If so, it removes the highlight before adding a new one.
However, my code currently works like this:
- Go through, the selections, line by line.
- For each line, check to see if it intersects with any existing highlights on the page.
- If so, remove the old highlight.
- Add the new highlight.
This assumes that selection rectangles never intersect across lines, though, whereas in sero’s example PDF, they do, thanks to the narrow line spacing. So in that case, the code adds highlighting to a line, and then when it checks the line below, the selection for that line intersects with the highlighting of the line above, so the highlight above gets removed.
I have fixed this by iterating through selected lines and removing all intersecting existing highlights before going through and adding them. This way there is no interference between the two operations.
2. Highlights and strike-throughs appear at the bottom of the page on macOS 10.12
This was harder to fix, because it’s an Apple bug, and took a little experimentation and logging lots of parameters. Essentially, Apple completely changed the way PDF annotations (including highlights and strike-throughs) are assigned as of 10.12 (or it might have been 10.11), deprecating old classes and replacing them with new ways of doing things. Unfortunately, they completely messed up and didn’t provide the necessary replacements methods to to be able to be able to create things like highlights and strike-throughs again until 10.13. In the interim, we were advised to stick with the out-of-date methods. Somewhere in their rewrites, though, they messed up those old methods too. 
Annotations (highlights etc) are added to a PDF page based on the selection rectangle. It should be straightforward: you ask the PDF view for its selection per line. Then you go through the selection and ask the PDF page for the rectangle of each piece of the selection. Then you create an annotation of a particular type (highlight, strike-through) with the selection rectangle as its bounding rectangle and add it to the page. What was weird that was, in this case, the bounding rectangle was correct - I logged everything and found the rectangles the same between 10.12 and 10.13 - and yet the highlights were appearing in the wrong place anyway. After a bit more digging I found that annotations have another obscure and not-very-well documented property called “quadrilateralPoints”. It turned out that in good annotations, these contained a mixture of zeros and the width and height of the selection rectangle, whereas the bad annotations had some odd negative numbers in here. So I worked out the necessary values and assigned them myself, and things now seem to be working. It therefore seems that on macOS PDFKit has a bug whereby the selection bounds isn’t correctly setting all of the internal properties of the annotation, causing it to appear in the wrong place.
So, yes, the short version is that these should - I hope! - both be fixed for 3.0.3.
Thanks to sero for the sample file, by the way!
All the best,
Keith
[size=80][/size]