In C++, the initialization value can be the result of a function call or a global variable.  But, of course, global variables have much different semantics in C++.

https://en.cppreference.com/w/cpp/language/default_arguments:

The names used in the default arguments are looked up, checked for accessibility, and bound at the point of declaration, but are executed at the point of the function call...

In any case, I agree that it is probably best to be conservative here and only accept constants as initialization values.

I think the problem with default argument values is a problem with the way functions are called and is not specific to anonymous functions.  For example, I see the same problem with an ordinary function:

octave> function foo (a = b) disp (a), end
octave> b = 1
b = 1
octave> foo ()
error: 'b' undefined near line 1, column 1
error: called from
    foo

If we use a constant or a function call to initialize the argument, then it works:

octave> function foo (a = 13) disp (a), end
octave> foo ()
13

octave> function foo (a = ones(2)) disp (a), end
octave> foo ()
   1   1
   1   1

Maybe I'm wrong about this, but I don't expect the function to capture the default argument values at the time it is parsed.  Instead, I expect the initialization expression to be evaluated at the point of the function call.  Where should the initialization values come from?  I don't think they should be values in the scope of the function itself.

So should we look to find them in the scope where the function call happens?  That makes the evaluation a bit complicated, looking for values in the calling stack frame and storing them in the function stack frame.

Maybe it would be better to limit the initialization values to be either constants or functions?

Adding jwe to the CC list.

The new refactoring of the symbol table and how functions are stored has stopped the segfaults reportedi in this bug report.  However, that is on the development branch which won't become Octave 6.1 for another year.  If there was an easy patch for 5.1 that would be nice.  Otherwise, I have dropped the priority to low since this is a

However, I still think the results of this example are incorrect

octave:11> a = 1;
octave:12> b = 2;
octave:13> %Segmentation fault
octave:13> fb_disp = @(a = b) disp(a);
octave:14> fb_disp();
error: 'b' undefined near line 2 column 17
error: called from
    @<anonymous>

I would have thought that the variable 'b' would have been replaced with the value 2 when the anonymous function was defined.

In terms of compatibility, we don't need to worry.  Matlab doesn't even allow default arguments to anonymous functions.

I attached a file containing test cases.

(file #46037)

When a default argument of an anonymous handle function is assigned a variable with the same name an error is shown. For example:

a = 1;
b = 2;

%Good
fb = @(a = b) a;
disp(fb());

%Error
fa = @(a = a) a;
disp(fa());

This behavior can be seen in nested functions:

function testfunction()

        a = 1;
        b = 2;

        function ret = fb(a = b)
                ret = a;
        end

        function ret = fa(a = a)
                ret = a;
        end

        disp(fb()); %Good
        disp(fa());        % error: 'a' undefined

end