I completely rewrote the underlying code for _line_ to resolve bug #39036. It also resolves this bug report. Closing as fixed.

@Lachlan,
Are you still planning to work on this?
I've regularly applied the cset but I've recently discovered that it gives rise to FAILs in copyobj.m and hgsave.m.
Maybe it is just the way the tests are set up, but I have no time for looking into it for a while.

I just noticed that there is overlap between this bug report and bug #39036. I'm adding a link, and will look into merging the patches.

I finally got round to testing this patch the last days. AFAICS it works OK.
Can this be pushed?

The attached patch supports all of the forms that Philip proposed, and leaves the properties of the lines as close to Matlab compatible as I could manage.
(file #36402)

Good point, jwe. I was totally forgetting that it is possible to access the data again.
The reason I wasn't getting any line was that I was drawing vertical lines,
and so each line was reduced to a single point.
Fortunately, Matlab gives
so it seems we can just transpose the data  much better than having to modify some subset of graphics toolkits to reinterpret the data.
Similar to your last example, Octave gives a diagonal line for the oneshot command
Thanks for all your guidance.

I see this behavior:
Then if I change the axis limits, the horizontal lines appear in the plot window.
So it looks like the problem is that line is doing something similar to broadcasting and creating two line objects instead of recognizing that there are two vectors of the same length.
When fixing this, it's important to make sure that the x and y data stored in the line object are oriented in a Matlabcompatible way. Do they retain their original orientation, or is one transposed so they are both row (or column) vectors?
I see that the following appears to work, so I think the bug is just in making line recognize the case of vectors with different orientations.

Thanks, Philip. I'll have a go at coding that somewhat efficiently.
Note that the bug report was about the lowlevel "line" command rather than highlevel "plot" command. I think that Octave's "plot" already handles these rotations, but "line" doesn't. (I checked your examples in Matlab, and it handles line flexibly too.) I just don't want to put too much additional checking into "line" because a "stem" command can call it hundreds of times, last I checked.

Lachlan, in your title example the length of the vector matches. That is all that Matlab needs.
What works (in ML 2014a) is e.g. (by the absence of error messages),
(note that in the last example the plot is rotated 90 degrees relative to the previous examples).
But ML has limitations:
...so one of the arguments to plot must be a vector, the other can be a matrix of which at least one dimension must have the same length as the vector argument.
AFAICS Matlab first tries to match dimensions/orientations as specified on the command line/instruction, and if it finds no match, tries rotating arguments until it finds common lengths, otherwise fails with an error message.

Thanks for checking, Philip. In the example I gave, neither dimension matches, but Matlab still draws the line. When I get to work, I'll check further.
Do we want to copy Matlab's forgiving behaviour exactly, partially or not at all? I'm in favour of copying whatever is quick to check for.

Matlab is very forgiving even if one is a matrix. AFAICS Matlab only checks which dimensions of the input vectors/matrices match and then use that for plotting.

If all X, Y and Z are vectors of the same length, Matlab doesn't seem to care whether they are row or column vectors.
Octave plots nothing if X is a column and Y is a row.
