Inconsistent default return_value_policy for positional and named arguments

m.def("foo", [](py::function func) {
    Bar a, b, x, y;
    ...
    return func(a, &b, "x"_a=x, "y"_a=&y);
}

In the code above, a and b are positional arguments and are converted to Python using return_value_policy::automatic_reference. On the other hand, the named arguments x and y use return_value_policy::automatic by default. Because of the inconsistency, &y will be converted as an owned pointer and it will later try to free memory on the stack (crash).

The ideal solution would be to apply automatic_reference to named arguments as well. However, this would be a breaking change so I'd like to propose it for v3.0. The break would only change the behavior for owned pointers, e.g. "name"_a=new Bar(...), which seems like it would pretty uncommon given that "name"_a=Bar(...) does the same thing.

The default automatic policy originally comes from the py::arg annotation for def with which named call arguments shares the syntax. So this change would also affect bindings of default arguments, but unless I'm overlooking something, switching to automatic_reference would similarly only affect the new T() cases.

Start by tracing the m.def call using py::function and compare how positional arguments and named arguments using "x"_a and "y"_a select return_value_policy. Also inspect the py::arg annotation behavior described in the issue. Done means resolving the inconsistent automatic versus automatic_reference behavior without the stack-pointer ownership crash, while accounting for the proposed v3.0 breaking change.