I fixed this to be Matlab compatible on the development branch in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/16b9ec39ff46). Closing report.

It produces an error:

Thanks Guillaume for testing with an ancient version of Matlab. I think it is safe to bring Octave up to date and announce the change in the NEWS file.
One last test
Does this silently return an empty matrix or does it produce an error because the second input is invalid?

There has indeed been a change in MATLAB's behavior.
R2010b returns:
while R2011a returns:
The help text is the same in both releases:
but with recent versions of MATLAB, it now states:

Oopsie that was the wrong window... (Octave)
Here's what ML r2014a really says:

@Rik, comment #7:
ML r2014a does this:
so it isn't quite empty as you expected.....

Attached is an attempt at a cset for this. It appears to work.
One of the things I get from reading the Matlab documentation is that matrices and vectors are not accepted inputs. I kind of agree that matrices don't make much sense. Maybe we should delete the implementation for that? On the other hand, I do kind of like the ability to use vectors. But if the input is a row vector, shouldn't the result be expanded down rather than across? It appears that the input is always made a column vector before expanding.
(file #34730)

Octave gets the single/double distinction correct. Here is a part of the code in data.cc for Flinspace
What does Matlab return for this?
It should be empty, but I wonder if the dimensions are 5x0? Although, I'm not certain that we need to copy them exactly in that regard.

Forgot to tack these on the end...
So only floating point arrays are valid, double or single, and the types of the first two arguments work according to the normal casting rules, type of 3rd argument doesn't matter.


I don't know what behavior to match, but the code in Octave is quite clear. As an example, liboctave/array/dMatrix.cc begins with
which guarantees that at least one element is returned regardless of the value of N.

I can't be sure or check now, but I'll bet that the strange behavior matches some old version of Matlab, even for negative values of N.
For sure, the fact that Matlab returns a 1x0 sized array is a new thing because old versions of Matlab did not have empty arrays with some nonzero dimensions.
Also, how does Matlab's linspace work for nondouble arguments? It looks like Octave doesn't preserve the type of the argument, so a double array is produced for something like
Also, what does Matlab do if the types of the arguments don't match?
I'm guessing that's another compatibility problem that could be a separate bug report.

I think there was already some special handling for linspace when N is small. According to the documentation,
What I think is supposed to happen is that for linspace (BASE, LIMIT, 1) it should return LIMIT rather than BASE. But for linspace (BASE, LIMIT, 0) it does seem that an empty matrix rather than LIMIT should be returned.
Just to check, can the original reporter run the following examples in Matlab and report the results?
Octave is a little strange because even for 1 it returns 20 which is most likely to be incorrect.

Confirmed w. Octave4.1.0+ (tip from Aug. 25, 2015) and verified in ML r2014a.
Release > dev + typo in title fixed.

Hello:
In Octave, linspace(10,20,0) returns
while in Matlab, the same order returns
I think this is an incompatibility issue. I'm using Octave 4.0, so I don't know if the behavior is also present in old releases
