confirming that (at first glance) our bar objects don't support the same color options as matlab's. (as with many other graphics objects, matlab has implemented separate object types for these things, in this case a 'bar object' is return that appears to be a subclass of a patch object with a few new bar features.)

Each set of bars uses a single color value, and our hggroup doesn't inherit the properties from patch objects to create multiple colors. It only gets 'facecolor' and 'edgecolor'.  With patches, those can either take colorspecs or other values that tell it to look for color data in other properties (cdata, facevertexcdata, etc.).

While the long range plan would be to support compatible 'bar objects', a nearer term wish list item could be to upgrade bargroup objects to also inherit the cdata and/or facevertexcdata properties to enable more compatible color control. (if no one else gets there first, i may create a wish list bug report for that)

so arbitrarily forcing cutoff there to 0.5 instead of 1 makes the figures overlap like matlab.  this does change the single bar width  even when plotted by itself.  I was concerned that would create an incompatibility, when I checked and saw that matlab also uses the same size bar width for single bar plots as multiple plots.  Forcing the 'cutoff' parameter to 0.5 also makes those plots matlab compatible in bar width, whereas now they're too wide.  I had assumed the comment/explanation above that section meant it was chosen for compatibility, but maybe not (unless that has changed with versions). 

the only problem in setting a single bar plot to a 0.5 'cutoff' is that the resulting narrower bar (from x=1.6 to 2.4 in this case) somehow results in the plot not being centered. it chooses x=1.6 as the left xlim.

it looks like some of the things we do for compatibility with single bar plot dimensions collide with this use case. in `__bar__.m` the default bar size is set to 0.8, but down below:

  elseif (nbars == 1)
    cwidth = 1;
    gwidth = width;
  else
    cwidth = gwidth = width;
  endif

so for 1 bar cwidth gets widened to 1. for multi-bar graphs it stays at 0.8.  if you try to superimpose two bar plots it's fine:

data = [10 2 10 10 10];

bar(data)
hold on
bar([1,2], data([1,2]))

need to look at what cases that wider width needs to be preserved, and how octave might be able to tell (maybe from ishold?) that it needs to stay at 0.8.

I have observed the following akward behavior of the bar plot command in Octave. I run the following demo code:

clear, close all

data = [10 2 10 10 10];

bar(data)
hold on
bar(2, data(2))

And I get a figure with a bar plot, where the second bar has a much bigger width compared to the other four bars in the plot. This second bar even covers some of its two neighboring bars.

I consider this imperfect plotting behavior of Octave, especially because in Matlab the same code gives me a plot with five nice bars of the very same width.