Thanks for testing. I'm switching the Item Group to Regression since this used to produce an error (even if not exactly on topic).

Appears to still be relevant.
Matlab 2017a:
Octave 4.2.1:

Since Matlab has added broadcasting in 2016B, is their behavior still the same as reported in the original submission which was for version 2015B?
I just want to make sure this bug is still relevant.

I'm attaching a patch, and the shell+awk scripts I used to generate it.
The operators are created by a maze of nested macros to minimize repeated code. It may be able to be simplified using templates, but my guess is that it would still require quite a bit of specialcase code. For example "A * B'" doesn't just transpose B and then multiply; it uses a particular library call that performs them together. Multiplication by a sparse, diagonal or permutation matrix clearly needs different code from multiplication by a full matrix etc.
This is right in the heart of Octave, and so it will probably take a lot of time and testing to get the patch approved. Any suggestions of how to test the hundreds of operators would be welcomed!
(file #36370, file #36371, file #36372)

Yikes. repeated code? or not identical enough for it to be functionalized and addressed in one place?

Yes, the arguments are being flattened to 2D implicitly, through a maze of macros in libinterp/operators/op????.cc
I'm preparing a patch, but there are lots of functions to fix (all combinations of single/double, real/complex, sparse, diagonal, ..., for half a dozen operators (A*B, A/B, A*B', A'*B, A\B, A'\B)).

Confirmed. FTR, did produce an error in 3.8.x and earlier, although it was not a nonconformant argument error:

This just came up on the help mailing list. I think the following example presents the issue concisely:
Each of those except the first should produce a nonconformant argument error. (Matlab 2015b errors out in these cases)
The email discussion thought maybe the issue had to do with broadcasting, but it now seems unrelated (and should be, since .* is uninvolved).
Is mtimes flattening the argument to 2D (from nxm * mxpxq to nxm * mx(p*q) ) and skipping any conformance checking?
(verified still exists in 4.0.1rc3)
