If you have a look at JuMP.build, which is called from solve() you’ll see that it discards the internal conic model before every solve. So it would take some restructuring to accomplish what you’re trying to do.
Also, it seems to me that SCS’s implementation of setwarmstart! is broken for duals and slacks because it doesn’t account for the transformations/permutations that are done between the MathProgBase conic format and SCS conic format, not to mention that dual_sol and slack keyword arguments are not part of the definition of setwarmstart! and shouldn’t be in a method called MathProgBase.setwamstart!.
The tidy path forward (i.e., to get PRs merged) would be to define a warmstarting method for duals and slacks in MathProgBase, implement it correctly in SCS, and then we can consider calling it from JuMP.
Thanks for the explanation; I tried to look-up setwarmstart! before, but there are just 4 sentences of explanation (as You linked);
Since SCS solution actually consists of (primal, dual, slack), maybe treat the tuple as v?
Are the transformations/permutations You mention done in conicdata?