Or what if the compatible behavior is prohibited in the safe mode?

What do you think if we leave the compatible behavior in the traditional mode?

Quoting from the Matlab documentation on empty arrays
The use of empty arrays, per se, is fine. As The Mathworks point out, it is often useful to be able to write an algorithm without having to special case whether there will be any elements to act on.
As an example, consider transforming between 1based indexing (which Octave uses) to 0based indexing (which the C language uses). This is pretty easy, you just need to subtract 1.
And this algorithm still works well if we put in a condition
And finally, it still works when there are no elements
I don't see any problem with allowing empty matrices to participate in mathematical operations. However, confusing codedependent issues arise if you say that looping over empty matrices is permissible.
For example, a common coding strategy might be to calculate some collection of elements and then loop over them like so.
For the command find(), Matlab returns the empty dimension in the second dimension (columns). But there is nothing that guarantees that an empty matrix has 0 columns. User code that defines the variable collection might choose the opposite convention and create 0xN style empty matrices in which case the for loop is operating N times.
Or something innocuous like a transpose could upset things.
Say I have an algorithm for which I want to operate on the rows of the matrix. Since the for loop returns columns, I need to transpose the matrix first.
So far that's fine. But if x is an empty matrix then the control becomes confusingly caught up with the decision to act on rows. In the case of find() the 1x0 result becomes 0x1 and the loop is executed once rather than zero times. It's also data dependent.
Lastly, this is very likely to lead to syntax errors. Most of the time, a programmer is going to want to do something with the loop element from the collection and this will require an indexing operation that fails because the element is empty.
Last example,
Under Matlab this errors out with "Index exceeds the number of array elements (0)". Currently, Octave has no problem with this code because it doesn't execute the body of the for loop when the righthand side is empty.

It seems that MATLAB has used the concept of nullable type.
From the documentation:
"An empty array in MATLAB is an array with at least one dimension length equal
to zero. Empty arrays are useful for representing the concept of "nothing" programmatically."
All nonabstract MATLAB classes have a method named empty. For example we can write:
It means that all non abstract types all nullable. Therefore we can make array of nulls and iterate over nulls.
Interesting discussion

I still disagree, and think we should leave Octave's current behavior as is.
In terms of UX/UI design I prefer to have the minimum number of principles and be able to to derive the behavior from these, rather than having lots of ad hoc exceptions.
For example, from the Declaration of Independence, "All men are created equal". But, starting in 1896 (Plessy vs. Ferguson and doctrine of "separate but equal"), you had to special case the general principle based on location. If you were in the North or West of the U.S. the general principle applied, but if you were in the South then you used the exception. This turned out to be a dumb idea and the U.S eventually went back to just one guiding principle in 1954 (Brown vs. Board of Education of Topeka).
My conception of a for loop over an object (as opposed to a range like 1:1000) is that it is equivalent to a foreach loop over the elements of the object. Hence, if the object is empty, there should be no looping. For me, looping over empty matrices means creating a mental exception only for "for" loops which seems unneccessary.
Of course, Matlab, like Moses, has said, "looping occurs over the number of columns". But, I guess I'm skeptical of the stone tablets. We don't always follow Matlab when they veer off the rails which I think is the case here.
As a practical matter, I think user's code would be improved by choosing the loop variable more explicitly, rather than relying on this questionable behavior. If you want to look a certain number of times, do that.
Also as a practical matter, I don't think this odd construct occurs with much frequency so changing the few instances that occur wouldn't be burdensome.
With all that said, this isn't an issue I'm particularly interested in arguing over. If you need to commit the patch for some clients who require 100% compatibility then it happens.

I disagree.
The for loop in Matlab is documented to loop over the columns of a matrix. When indexing an Nd array as a matrix, Matlab joins the columns from all dimensions as if they were one. Octave also does this redimensioning when evaluating an Nd array in a for loop command. The behavior is only different when the leading dimension is the only zero dimension.
For example, if you have an array like x = ones (2,3,4), you can write x(:,1), x(:,2), ..., x(:,12) to index all the columns. This behavior is consistent for zerosized arrays. If you have x = ones (0,3,4), you can perform the same indexing. Only when one or more of the dimensions beyond the first is zero do you have no columns to index in the redimensioned array. By not looping when only the first dimension equal to zero, we are less compatible with Matlab and inconsistent with other array indexing.
We've already copied the weirder part of for Nd array for loops, which is to always assign the redimensioned value to the loop index even when there are zero trips through the loop.
I believe the attached change makes the behavior compatible.
(file #46234)

I agree with the earlier decision and upholding it, closing.

We decided not to implement this questionable behavior back in 2017. Is there new evidence that would make us want to reverse that decision? This is very much a corner case, and very odd. My vote is to leave the decision as is and close this report.

Again, that looks like an artifact of implementation. How would one guess that in loops, ND arrays are squeezed to 2D before using as the looping structure. All very unintuitive, hence a bad UX/UI, even if an underlying principle can be found.

Rik: It is consistent behavior if you first reshape the Nd array in
into a matrix using ndarray(:,:).

@jwe: Emphasizing the irrationality of the behavior, the example you gave executes 0 times rather than 3.

I had forgotten about the previous bug report but just found it now. There, I wrote, "These seem almost like some kind of accident of implementation rather than conscious decisions about how things should work. But who knows, right? Is this Matlab behavior documented anywhere?" I suppose it is documented, in that for loops are documented to iterate over the columns of a matrix.
BTW, what does the following do in Matlab?
Does it loop three times or not at all?

@Mike: good digging. I'm inclined not to emulate Matlab. Adding jwe to the CC list.

For reference, this was last discussed in bug #50893. At that time, it was decided to be intentionally incompatible, the evaluator was changed to not loop over any empty array expression (https://hg.savannah.gnu.org/hgweb/octave/rev/fd7a16594614).

I think it's debatable how useful this is. It seems to be an artifact of the implementation: Matlab loops over the number of columns regardless of whether the actual expression is empty.
For reference, this loop executes three times in Matlab

@Kai: I discussed it with jwe on IRC, I think he is fixing it.

Evil statement ;) And it loops even in Matlab R2018b, one can see 'hey' once there, while Octave does not loop.

The following code
does not loop, while it should since (3:2)' has one column. It used to loop at least up to 4.2.2.
