This might be an old bug, but I was sent some fonts that were obviously produced with Glyphs, in which all coordinates of all points were proper integers, but widths of hints were in fractional coordinates, raising red flags. So it seems that the (not so good) auto-hinter does or did not respect the grid spacing.
(maybe this can clarify age/version: hotconv 1.0.109;makeotfexe 2.5.65596)
I think you or Jens reported that some time ago and I fixed something about it (if I remember correctly).
And what red flags where risen? It is certainly unusual to have fractional stems but it should still work.
If I remember correctly, what you fixed was that hints generated in Glyphs were rounded to int on interpolation.
This is somewhat different, in that the (Adobe?) autohinter on export generates a hint that has a fractional width. E.g. if the top line segment of a stem is not exactly horizontal, so the left height of the stem is 50 and the right height is 51, then the generated hint will be 50.5.
The red flag said “fractional coordinates detected”
But then I only saw integer coordinates, until I made hints visual.
I think that if a font is meant to be integer (grid spacing 1) it should not get fractional coordinates behind the users back.
That sounds more like a bug report for the autohinter. The autohinting on export is directly producing the char string that goes into the font. So the rounding needs to be applied in the Adobe code.
@jkutilek, can you send me a sample font that triggers the fractional hints?
Quote from de Groot: “never trust auto-hinting”.
Since the Adobe code is built into Glyphs, maybe Glyphs should do another sanity check after the Adobe magic. Needles to say that Adobe should not be trusted either 
As such, placing a PostsScript hint in between actual coordinates makes sense, e.g. for tapered strokes like an exclamation mark, to hint more or less the average thickness of a stroke. Which also means that manual hinting solely based on linking to points might not suffice.
The difference should matter as the blueFuzz should catch the points anyway.
I do not understand, I was not talking about zone alignment.
BlueFuzz is an old mechanism for extending zone thickness, of which Adobe recommends since a few decades not to use it (set to zero).
(But then again Adobe probably forgot to realize that even though BlueFuzz might have been officially intended to compensate for inaccurate drawing on ancient 13" computer screens, it can actually help to control the design of the font, since - as far I understand - the rounding of zones depend on their fuzzless thickness, and you might not always want to extend the zone thickness to the highest overshoot that needs to align, especially not with the latest and greatest Adobe Rasterizer Extra Powerful Zone Pushing, which I find pretty awful in many situations) Never trust auto hinting
As far as I know, BlueFuzz doesn’t influence the rounding of the zones, otherwise it would be equal to just making the zones bigger by the BlueFuzz amount in each direction.
Yes, I wrote the same, but probably less clear 
If I call the AFDKO autohinter directly, it even warns about this kind of stem:
$ autohint NewFont-Regular.otf
Hinting font NewFont-Regular.otf. Start time: Fri Jan 8 15:33:01 2021.
Hinting h.
The line from 600 57 to 0 56 is not exactly horizontal. Horizontal linear stem near miss: 57 instead of 56 at 0 to 57. Horizontal linear stem near miss: 56.5 instead of 56 at 0 to 56.5. Horizontal linear stem near miss: 56.5 instead of 56 at 0 to 56.5.
Saving font file with new hints...Fri Jan 8 15:33:01 2021
Done with font NewFont-Regular.otf. End time: Fri Jan 8 15:33:01 2021.
NewFont.zip (4.3 KB)
Oops … I misread fuzzless for fuzziness