OK, I guess I should have been a little more descriptive about exactly the problem is.  Or I should say "was", because the oldcol!=_columns code is gone and the width now behaves properly.

It's subtle.  What PN describes is the behavior of the GUI's terminal window, but I was referring to Octave's internal output format.  The callback (and the SIGWICH) are meant to indicate to the core that the terminal size has changed, e.g., it is no longer 80 characters wide.  The internal formatter uses the new size to determine how many columns of a matrix can be printed on one line.

It's hard to illustrate with examples when there is no window, but if one would have shrunk the terminal window to the minimum columns, exit, then relaunch, the output would look something like:

>> pi*ones(10)
ans =

 Columns 1 through 7:

   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416

 Columns 8 through 10:

   3.1416   3.1416   3.1416

Resizing would correct the appearance as (after another print out):

>> pi*ones(10)
ans =

 Columns 1 through 3:

   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416

 Columns 4 through 6:

   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416

Well, it's been corrected now, and the internal Octave format line width is correct.

I still prefer using SIGWICH.  That's the mechanism that other terminal emulators use (e.g., Gnome Terminal).

raising a SIGWINCH signal would be OK for systems that have it, but Windows does not.

But we also need to do something else on Windows systems anyway because currently narrowing a terminal window and then making it wider causes existing lines in the window to be truncated.  I think I have a possible fix for this.  I'll post it here when I have something that works and that I'm happy with.

3.9.0+ (where I applied your patch to) seems to work OK on Linux and on Windows/MinGW.
To be honest I fail to see any difference as regards resizing the GUI terminal; it just works fine.

One thing I note is that on Linux, while making the terminal narrower, the pager line at the bottom disappears; but as soon as I touch an arrow key or so it reappears.

What never worked fine on MinGW is that when widening a too narrow terminal (where long lines wrapped), the wrapped characters/words jump back to the right once they fit in.

In main-window.cc is the following line which I believe is meant to force the Octave core to update the Readline terminal size so that Octave properly formats its output:

+verbose+
octave_link::post_event (this, &main_window::resize_command_window_callback);
-verbose-

Currently if the window is resized then the terminal will properly adjust.  The reason it doesn't work on the first resize due to restoring user settings is that QTerminal code has this conditional:

  _resizing = (oldlin!=_lines) || (oldcol!=_columns);

  if ( _resizing )
    {
...
    }

which I presume cuts down on kernel traffic a little bit since it changes the scale from pixels to characters.  (I.e., sizing isn't changed with every pixel change.)

Attached is a changeset that removes the use of a callback function and instead raises a signal at a location hopefully after the GUI objects are initialized and the Octave core has reached the point where it is capable of recognizing kernel signals.  Now, whether that is true and is still open for timing problems I'm not sure because kernal signals isn't something I've worked with a lot.  But I think the signal approach is just about right and a more conventional way of doing this.

What the ramifications are for Windows systems I'm not sure.  Perhaps it isn't even a problem problem for Windows.