Background

• JuMP has long supported nonlinear subexpressions created with @NLexpression.
• The AD system in MOI.Nonlinear has support for representing expressions, and dealing with them efficiently
• When we created ScalarNonlinearFunction, we did not create an analogous ScalarNonlinearExpression object.
• In most cases, nonlinear expressions make little difference, or are a minor win.
• An upside and a downside is that it's up to users to decide which expressions should be common. I have seen, anecdotally, that users on the forum either use no @NLexpression, or they made every possible expression a @NLexpression
• Best performance is to judiciously use common subexpressions where it would make a difference.
• The best real-world example we have is @mitchphillipson's MCP model: Poor performance in complementarity models #3729 (comment)

The question is how to achieve this in JuMP.

I opened an issue in MOI: jump-dev/MathOptInterface.jl#2488

Short of rewriting much of the MOI.Nonlinear module to use a single DAG of expressions (instead of the current tree), we could pass the expressions through to MOI, and then attempt to detect common subexpressions. This would rely on a heuristic of when it was beneficial to do so.

A simpler approach would be to add a "nonlinear expression" set to MOI (and JuMP), just like we've done for Parameter.

A crude API would be:

@variable(model, y in CommonSubexpression())
@constraint(model, [y; f(x)] in CommonSubexpression())

with the fallback to a bridge

@variable(model, y)
@constraint(model, y == f(x))

and maybe one for MCP:

@variable(model, y)
@constraint(model, f(x) - y ⟂ y)

We could come up with nicer syntax, for example:

@expression(model, y, f(x), NonlinearSubexpression())