Torkel Loman

If the user changes `d` then that is its new value (since it now has a value, the default is no longer used). Initialization problems never really were a thing...

Right, so I agree that defaults will have effects down the line. However, this was a thing before we started working with initialization and focus on DAEs, I don't see...

Well, it was the intended behaviour, there were bugs going around before v9 as well. In this case, we only had the bug being reported this spring.

But for this case we should be good, right? Let me explain our application ### Conserved quantities in chemical reaction networks We have a reaction system with a single thing...

Basically, the problem we see here is the same as we see when we have a parametric initial condition: ``` using ModelingToolkit @parameters p d X0 @variables t X(t)=X0 D...

If there are performance involved, I think @hersle makes a good point. To keep `setu` and `setp` performant that might be required. Generally, in Catalyst, I think we recommend that...

I think under ideal circumstances we could have a dependency graph to ensure that defaults are updated, but I understand that that is lots of work given the limited resources...

For now, having intended behaviour in actual simulations should be good, but I am correct that this does not work for defaults using either parameters/variables? I.e. this ``` using ModelingToolkit...

the mwe was carried out on v6.80 :(

Right, but default solver choice is currently possible for both `ODEProblem` and `NonlienarProblem`, having it for `SteadyStateProblem` seems like a natural next step?