> I see no difference between the default behavior of August 13, 2014 Emacs Trunk (before applying the patch), versus after applying the August 12, 2014 patch of nsterm.m.

I wasn't expecting too much from it anyway :-(

 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >
 > *window-frame-dump*_06_01_2014.txt
 >
 > frame pixel: 1926 x 1058   cols/lines: 174 x 52   units: 11 x 20
 > frame text pixel: 1900 x 1054   cols/lines: 172 x 52

I suppose the 1926 is now 6 pixels too wide for a display width of 1920
and this comes from adding the 6 pixels for the changes in the fringe
calculations.  Correct?

 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >
 > *window_frame_dump*_08_13_2014.txt
 >
 > frame pixel: 1920 x 1058   cols/lines: 175 x 52   units: 11 x 20
 > frame text pixel: 1900 x 1054   cols/lines: 172 x 52

Are these now the intended values?

BTW have you set `frame-resize-pixelwise' to t?  If you don't, Emacs
will round sizes to character multiples.

 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >
 > Printout with `toggle-frame-maximzed` following Emacs -Q
 >
 > frame pixel: 1920 x 1000   cols/lines: 275 x 62   units: 7 x 16
 > frame text pixel: 1885 x 996   cols/lines: 269 x 62

This means that the width isn't too far away from the other two but the
height is quite different - maybe to account for a taskbar.  I attach
yet another patch for nsterm.  You have to set `frame-resize-pixelwise'
in your .emacs to some non-nil value for it (but you should have done
that already as mentioned above).

martin