Awesome =) In the spirit of your changes Rik, I added a small change for "eye()" in cset https://hg.savannah.gnu.org/hgweb/octave/rev/a533a7c4d2cc .
Regarding comment #8 for Matlab R2018b:
Same for Octave now (with your patches applied) =)
I really consider this item to be fixed/closed as well. Thank you Rik and jwe for your help!

I pushed another changeset which fixes the remaining issue (https://hg.savannah.gnu.org/hgweb/octave/rev/d6581134daaa). This revealed that Octave was doing an inappropriate conversion in rand() of a dimension vector in to an int type rather than an octave_idx_type.
Marking bug as fixed and closing report.

For compatibility, what does Matlab return for
???

I pushed a changeset that fixes all of the utility matrices like eye, ones, etc. as well as rand. See https://hg.savannah.gnu.org/hgweb/octave/rev/373fe1608f7c. I also added some BIST tests while I was at it.
The remaining issue is a dimension vector such as
which still passes.

Rik, thanks for taking care of this. I applied file #45170 and can confirm the outputs of comment #5.
It improves the situation for the creation matrices, except for "rand". I think it should be applied to all four overloaded versions of libinterp/corefcn/data.cc (fill_matrix) and we leave this report open.

Attached is a quick diff that works for me. The error message is different now, but maybe that is okay?
Previously,
Now,
It doesn't mention that the dimension must be a scalar integer. On the other hand, it identifies the argument that is in error far better.
The diff is trivial
However, this still doesn't error out if a dimension vector is used.
That is a different codepath in the function fill_matrix in data.cc.
(file #45170)

Agreed. This was done for Matlab compatibility, but I never liked it either because I prefer strict input validation. Marking bug as confirmed.

OK, I'd be glad to require dimension arguments to be integers. I never liked the rounding behavior anyway. It was only done in Octave for compatibility, as far as I know.

Okay, my Matlab experience refers to a much shorter timespan ;)
At least R2018a errors in all cases with a hint to use integer dimensions only.

Originally, Matlab rounded (I think) noninteger values passed as dimensions to functions like eye, ones, and zeros. So Octave did the same for compatibility. What does modern Matlab do?

While fixing another bug, I received errors, because of potentially erroneous test cases (maybe copy&paste errors from "sprand")
https://hg.savannah.gnu.org/hgweb/octave/file/20e294a607af/test/diagperm.tst#l80
Additionally, Octave does not error on the following statements, and silently creates nonsense:
Similar for "zeros" and "ones" (only the first as example given below:
