Function backend_only_refusal 

pub fn backend_only_refusal(
    options: &OptionsList,
    reg: &RegisteredOptions,
) -> Option<String>

The refusal for a run whose options configure nothing but backends pounce does not ship, or None.

This is the boundary of the warn-don’t-refuse rule above, not an exception to it. That rule rests on one premise: the file has other business here, and failing it over ma97_order would reject a run the caller wanted for the sake of a knob it never touches. When the backend knobs are all that is there, the premise is gone — nothing in the file survives, so there is no working run left to protect. Warning and solving anyway answers a request to tune the linear solver by tuning nothing and reporting success, which is the shape of gh#677 rather than a fix for it.

Two gates, and both are needed:

1. Something was actually asked for — at least one backend knob is set to a non-default. A file that spells out ma97_u 1e-8 (the registered default) asks for nothing and still gets nothing said about it, exactly as a_backend_knob_at_its_default_is_silent requires.
2. Nothing else was mentioned at all. The test is presence in the options list, not set_to_a_non_default: a caller who writes tol 1e-8 has stated a real intention about this solve even when 1e-8 is the default, and a file with real content in it is the portable-ipopt.opt case the warning exists for. Presence is also the safe direction to be wrong in — it can only make this refusal rarer. [DELIVERY_MECHANISM] is the one exemption, and it exists so that pointing at a backend-only file with option_file_name is not permanently exempt from the refusal that file has earned.

Note that a file selecting the backend it tunes never reaches here: linear_solver=ma97 is refused before this, by crate::application::IpoptApplication::unimplemented_linear_solver. What lands here is the file that tunes MA97 without ever saying so.