I'm going to close this report.  There is a bug open about the problems with printing modifying the plot view (bug #55500) and one about the direction of normals (bug #55493).

I changed the dump_demos script to use the same ColorOrder as the rest of Octave (https://hg.savannah.gnu.org/hgweb/octave/rev/16f18b0ef642).

@Markus: If the results are do approximations then using a finer grid should help.  I changed light demo #5 from

 [x,y,z] = meshgrid (-.2:0.04:.2, -.2:0.04:.2, -.2:0.04:.2);
 val = (x.^2 + y.^2 + z.^2);

to

 [x,y,z] = meshgrid (-.2:0.01:.2, -.2:0.01:.2, -.2:0.01:.2);
 val = (x.^2 + y.^2 + z.^2);

This changes the number of points in val from 1331 to 68921.  When I run the light demo on Matlab and Octave they now appear the same.  So, that seems to be the way forward.

For demo #5 I checked in a changeset (https://hg.savannah.gnu.org/hgweb/octave/rev/8bed6950ddde) where instead of the range operator I use linspace and I increased the number of points from 11 to 12.  This produces results which match those of Matlab.

rng = linspace (-0.2, +0.2, 12);
[x,y,z] = meshgrid (rng);

It might be useful to replace the range operator in other demo blocks of light as well, but #5 was the most glaring to me.

The different colors are a consequence of the dump_demos.m script.  There is this bit:

 ## Create script beginning (close figures, etc.)
  fid = fopen (mfile, "w");
  fprintf (fid, "%% DO NOT EDIT!  Generated automatically by dump_demos.m\n");
  fprintf (fid, "function %s ()\n", funcname);
  fprintf (fid, "set (0, 'DefaultAxesColorOrder', ...\n");
  fprintf (fid, "  [ 0.00000   0.00000   1.00000 ;\n");
  fprintf (fid, "    0.00000   0.50000   0.00000 ;\n");
  fprintf (fid, "    1.00000   0.00000   0.00000 ;\n");
  fprintf (fid, "    0.00000   0.75000   0.75000 ;\n");
  fprintf (fid, "    0.75000   0.00000   0.75000 ;\n");
  fprintf (fid, "    0.75000   0.75000   0.00000 ;\n");
  fprintf (fid, "    0.25000   0.25000   0.25000 ]);\n");
  fprintf (fid, "close all\n");
  fprintf (fid, "more off\n");
  fprintf (fid, "diary diary.log\n");

This ensures that we get reproducible results between Octave and Matlab.  However, Octave has moved to a different ColorOrder.

octave:1> get (0, 'DefaultAxesColorOrder')
ans =

   0.00000   0.44700   0.74100
   0.85000   0.32500   0.09800
   0.92900   0.69400   0.12500
   0.49400   0.18400   0.55600
   0.46600   0.67400   0.18800
   0.30100   0.74500   0.93300
   0.63500   0.07800   0.18400

We could just update the dump_demos.m script with the new values.  I think, however, that we might have had a reason for doing this because the first three lines are primary colors of blue, green, and red.  This stark a difference is easy to spot.

I guess I would advocate doing the experiment and updating the DefaultAxesColorOrder and then running dump_demos with just one toolkit (qt) on Linux and see if the result appears visually okay.  If it does then we can make the change permanently.

I also think that we need to include the viridis colormap and set it as the default colormap.  The default used by Matlab is similar to viridis, but not identical.

To make sure that we are talking about the same thing in demo light 5: Are you referring to the outline of the specular reflex (the bright white spot)?
I'd say that outline is shaped slightly differently because Matlab seems to use a different algorithm to generate the faces for "sphere" (better visible in "demo reducepatch"). That leads to the faces being inclined slightly differently in Octave and in Matlab which in turn leads to slightly different lighting effects.

Wrt the isonormals demo: Matlab seems to point some of the automatically calculated normals in the opposite direction from what Octave does. That should probably be handled in a dedicated bug.

Wrt the light demos: I don't see what you describe in demo 5. Could you please elaborate?
In the right column of demo 9 and 10, it looks like "unlit" has the same effect as "lit" in Matlab (like you already wrote in comment #0). I consider this a bug in Matlab and believe Octave is actually doing better in this case.
To be honest, I don't know what Matlab is doing in the upper left subplot of demo 10. It doesn't look "reverselit" to me...

I tested the scatter demo #3 and it works fine.  I think there may have simply been trouble when the script to create the plots had to be split in to multiple pieces in order to work on Matlab.

The regression with printing rotated text is pretty serious.  I filed a new bug report about that (bug #55485).

I changed our %!demo code to use Matlab syntax (https://hg.savannah.gnu.org/hgweb/octave/rev/9728b61ef67e).  It should work the next time we run compare_plot_demos.

I filed bug #55484 about a regression in the printing of dashed lines with the qt toolkit only.

I filed a new bug about 3-D ticklengths (bug #55483).  In the meantime, I scaled the lengths produced by Octave's algorithm to get better visuals (https://hg.savannah.gnu.org/hgweb/octave/rev/acefc0bca74a).

No need to fix fplot, I think it is more useful to add the legend.

I fixed up stem (https://hg.savannah.gnu.org/hgweb/octave/rev/b52f6b0667eb) and bar (https://hg.savannah.gnu.org/hgweb/octave/rev/b52f6b0667eb).