OK, this is starting to make sense to me. If I'm understanding this, the point of your series is that the font has a consistent size based on the unit stored in the font. If it's a physical unit like inches then the font's size in world coordinates changes based on the graphics page unit, so that it maintains the same physical size. Since GdipMeasureString reports world coordinates you see the measurement change while the pixel size should stay the same based on the device dpi.
This would mean that get_font_hfont needs to account for font->unit, so that it can calculate the right pixel size based on the device dpi. It currently doesn't. In fact, it appears we're trying to do this calculation in GdipCreateFont, when we don't have enough information for it. This probably only works when the Graphics object has the same dpi as the display.
Since get_font_hfont is applying the page transformation to font sizes, we are still scaling our fonts based on the graphics page unit, when your tests show that in at least some cases we shouldn't be. I think what you've actually done is cancel out the convert_unit() factor that get_font_hfont had applied, by changing the measurement, and I don't think that's right. The pixel size should always relate to the world size based on the transform used by GdipTransformPoints. It's the pixel size that needs to change, not the relationship between pixel size and result.
This also raises some questions about the world transform and page scale. If I have a font with a size of 1.0 inches, and I render it on a graphics with no world transform or page scale, I guess it uses a pixel size equal to the dpi of the graphics object. If my graphics object has a scaling world transform or a page scale of 2.0, does the font render at twice the normal size in pixels, or is its size unaffected by those things? Are these cases where we'd see a difference between UnitWorld, UnitPixel, and UnitDisplay?