Less restrictive promote_u0_p

[devmotion]

#3572 broke our downstream code that uses p::Functions (to be evaluated at integration time t) as parameters.

Given that none of the other involved functions restricts p explicitly to a Union{AbstractArray,MTKParameters}, IMO it seems natural to use DiffEqBase.promote_u0 as a generic fallback and not only in the case p::AbstractArray.

[ChrisRackauckas]

Wouldn't p::Function go down the MTKParameters path with the splitting? Do you have an MWE we can test against here?

[devmotion]

The system itself is not constructed with ::Function parameters. The use case is a bit special, remake is called on an ODEProblem with an MTK system but f is explicitly set to a custom wrapper of the original ODE function that unpacks ::Function parameters and p is explicitly set to such a ::Function parameter.

[devmotion]

remake ends up in MTK since an MTK system is involved.

[ChrisRackauckas]

Oh is this the Chris E hack in Pumas for lifting the covariate constructions? I really don't like how that interacts with the interface... though we might as well keep it alive. Definitely not something to document telling people to do it 😅

[devmotion]

Could we tag a new release of MTK?