Looks great. At a high level, I think this is pretty similar to what we had done internally (wrapped the C API with ABSL/C++ bindings first).

I see that you clear variable/constraints instead of deleting them in your C++ wrapper. Your API does support deletion yes? I understand that in some settings, clearing is faster than deletion, but I guess our perspective is that the user can clear themselves if they want clear. If they really need deletion (e.g. they are managing a very large number of cuts/columns), then we want to offer it to them. Also, with your deletion API, do variables have stable ids, or indices, and all the indices change on each deletion?

A big challenge that is not yet complete is to pass the integration tests, e.g. have a file like this:

https://github.com/google/or-tools/blob/stable/ortools/math_opt/solvers/gscip_solver_test.cc

(The gurobi version of this file appears not be exported to the open source project? Not sure why.) This always ends up being harder than it looks, due to a combination of the tests being a bit fragile and the solvers all being a little different (we try to run the same tests for all the solvers, with some solver specific configuraiton).

Specifically re MPSolver, inside of Google we are basically done adding features here, but we are continuing to work on the MPModelProto path e.g. here:

https://github.com/google/or-tools/tree/stable/ortools/linear_solver/proto_solver
https://github.com/google/or-tools/blob/stable/ortools/linear_solver/solve_mp_model.h

(but nothing conic). You would need to check with lperron, maybe we don't even want to merge any more mpsolver changes that don't just delegate to solving with the proto.

The people working the Mosek stuff are US based, so we will probably look more closely after thanksgiving.