I understand that the primary goals are lightweight and speed, and I fully appreciate those goals.

I see that the current draft only deals with glyph rows ending _prior_ to the fill-column, and then an extra glyph is added subsequent thereto for the purposes of creating a visible fill column indicator.

I would suggest devising a mechanism that can intersect characters (at any given X coordinate) for glyph rows that extend beyond the fill-column, including, variable pitch and mono-spaced fonts.  Attached is a screenshot of what this would look like in Emacs.

Admittedly, the code used to create the visible fill column indicator in the screenshot (capable of intersecting characters at any given X) is anything but lightweight _and_ it is only for GUI versions of Emacs (NS/W32/X11).  It is, however, pretty darn quick....

Perhaps there is an overlay that can be used that is capable of intersecting characters, or a thin vertical window spanning the window-body-height that is one pixel wide; e.g., all three GUI platforms can create a vertical window as thin or thick as desired (such as a vertical scroll bar).  There are platform options to repaint or suppress repainting when removing windows ....  Emacs already has the ability to redraw the glyphs that fall within a given rectangle using the w->current_matrix after update_window has already done its thing ....

In case anyone is interested in the code used to generate the screenshot below, the latest proof concept patch for feature requests 17684 / 22873 is now at version 19.002:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22873#134