Return Feasible_Point_Found when restoration fails at (almost) feasible point?

[Robbybp]

It seems like Feasible_Point_Found or a new Acceptably_Feasible_Point_Found status would be a more useful return code than Restoration_Failed when the point of failure is (almost) feasible. This is an issue because many interfaces, e.g. Pyomo and JuMP, treat Restoration_Failed as an error even though converging to a feasible point is fine for a lot of applications. This could be handled in the AML interfaces, but I'm wondering if there is any interest in changing the IPOPT return code in these situations.

[svigerske]

Currently, the Feasible_Point_Found status is reserved for square problems (https://coin-or.github.io/Ipopt/OUTPUT.html).

Several of Ipopt's SolverReturn codes do not give information on the feasibility status of the solution. Next to RESTORATION_FAILURE, also for MAXITER_EXCEEDED, CPUTIME_EXCEEDED, WALLTIME_EXCEEDED, STOP_AT_TINY_STEP, USER_REQUESTED_STOP, and ERROR_IN_STEP_COMPUTATION it is not clear whether the last solution is primal or dual feasible.
However, interfaces can query the final constraint violation and set their status codes accordingly, as it is done by some AML interfaces.