OrdinaryDiffEq v7 and all associated breaking updates

[ChrisRackauckas]

This is a PR branch that is accumulating all of the breaking updates for the OrdinaryDiffEq v7 and all sublibraries (including DiffEqBase) with this. This does not include SciMLBase breaking change because that's in a separate repo, and RecursiveArrayTools.jl, etc. Changes to here will be added by targeting feature PRs to it.

Current PRs in here:

• OrdinaryDiffEq v7 and all associated breaking updates #3242

[ChrisRackauckas]

@JuliaRegistrator register subdir=lib/OrdinaryDiffEqExplicitTableaus branch=v7

[JuliaRegistrator]

Comments on pull requests will not trigger Registrator, as it is disabled. Please try commenting on a commit or issue.

[ChrisRackauckas]

@JuliaRegistrator register subdir=lib/OrdinaryDiffEqImplicitTableaus branch=v7

[JuliaRegistrator]

Comments on pull requests will not trigger Registrator, as it is disabled. Please try commenting on a commit or issue.

[ChrisRackauckas]

@JuliaRegistrator register subdir=lib/OrdinaryDiffEqRosenbrockTableaus branch=v7

[JuliaRegistrator]

Comments on pull requests will not trigger Registrator, as it is disabled. Please try commenting on a commit or issue.

[ChrisRackauckas]

OrdinaryDiffEq v7 Invalidation & TTFX Analysis

TTFX Results (all precompiled)

Metric	Time
using OrdinaryDiffEq	2.1s
First ODEProblem	0.015s
First solve(Tsit5)	0.045s
First solve(Rosenbrock23)	0.085s
First solve(FBDF)	0.019s
First solve(Vern7)	0.017s
First solve(default)	2.4s
Total TTFX (load + Tsit5)	2.2s

Subpackage load times:

• OrdinaryDiffEqCore: 0.5s
• OrdinaryDiffEqTsit5: 0.025s (almost free on top of Core)
• OrdinaryDiffEqRosenbrock: 0.7s
• OrdinaryDiffEqBDF: 0.67s

The default solver path is the bottleneck at 2.4s TTFX because it compiles the autoswitch logic.

Invalidation Analysis: 49 trees, 1838 total invalidations

By source package:

Package	Trees	Invalidations	Root cause
StaticArrays	7	861 (47%)	unsafe_convert, convert(Array), instantiate(Broadcasted)
DataStructures	9	203 (11%)	iterate(SwissDict), merge(RobinDict), +(SortedContainer)
NonlinearSolveFirstOrder	1	163 (9%)	initialization_alg(NonlinearLeastSquaresProblem)
NonlinearSolveBase×SMC ext	1	162 (9%)	is_extension_loaded(Val{:SparseMatrixColorings})
NonlinearSolve	1	132 (7%)	initialization_alg(AbstractNonlinearProblem)
SciMLBaseForwardDiffExt	4	96 (5%)	anyeltypedual methods
OrderedCollections	2	60 (3%)
ForwardDiff	3	48 (3%)	convert(Dual)
Other	21	113 (6%)

Incremental invalidation (loading order matters)

Step	Trees	Invalidations	Key culprit
OrdinaryDiffEqCore	5	65	DataStructures (58)
OrdinaryDiffEqTsit5	0	0	Clean!
OrdinaryDiffEqRosenbrock	21	553	StaticArrays (454)
OrdinaryDiffEqBDF	26	1172	StaticArrays (407), NonlinearSolve* (457)
OrdinaryDiffEqVerner	2	50	SciMLBaseForwardDiffExt
OrdinaryDiffEqDefault	0	0	Clean!

Major Invalidators & What Could Be Done

1. StaticArrays (861 invalidations, 47%) — THE biggest problem

• Used by: OrdinaryDiffEqBDF (for SArray in BDF utils/caches), OrdinaryDiffEqNonlinearSolve (for StaticArray dispatch in DAE init), OrdinaryDiffEqDifferentiation (only for typeof(u0) <: StaticArray check)
• Could it be an extension? For OrdinaryDiffEqDifferentiation, the usage is just an isa check — could use StaticArraysCore instead (no invalidations). For OrdinaryDiffEqBDF, the SArray usage in bdf_utils.jl and bdf_caches.jl is integral to the BDF coefficient computation. For OrdinaryDiffEqNonlinearSolve, it's used in DAE initialization dispatch.
• Recommendation: Replace StaticArrays with StaticArraysCore where possible (the type-checking in Differentiation). For BDF, the SArray construction is load-bearing — consider if these could use NTuple or move StaticArrays to an extension. This is the single biggest win available but requires careful work on BDF internals.

2. DataStructures (203 invalidations, 11%) — used only for BinaryHeap

• Used in OrdinaryDiffEqCore for BinaryHeap{T}(FasterForward()) in tstop/saveat/discontinuity initialization (3 call sites in solve.jl)
• Recommendation: Replace with a minimal custom binary heap or sorted Vector. Eliminates 203 invalidations from the critical Core path that every user hits. DataStructures brings SwissDict, RobinDict, SortedContainer etc. that all add piracy-adjacent methods.

3. NonlinearSolve ecosystem (457 invalidations, 25%) — initialization_alg + extension loading

• NonlinearSolveFirstOrder adds initialization_alg(::NonlinearLeastSquaresProblem) which invalidates 163 precompiled methods
• NonlinearSolveBase's SparseMatrixColorings extension invalidates 162 via is_extension_loaded
• NonlinearSolve itself adds initialization_alg(::AbstractNonlinearProblem) for 132 more
• Recommendation: Upstream issues in NonlinearSolve.jl / NonlinearSolveBase.jl. The initialization_alg fallback uses overly broad signatures causing cascading invalidation. The is_extension_loaded(::Val) pattern is a known anti-pattern.

4. SciMLBaseForwardDiffExt (96 invalidations) — anyeltypedual

• The ForwardDiff extension adds specialized methods for anyeltypedual that supersede the fallback
• Recommendation: Upstream issue in SciMLBase. The fallback anyeltypedual(x, counter) should be typed more narrowly.

5. ForwardDiff (48 invalidations) — convert(Dual)

• convert(::Type{D}, d::D) where D<:Dual supersedes convert(::Type{T}, x::T) where T<:Number
• Recommendation: Upstream ForwardDiff issue.

Non-breaking Improvements (no further breakage needed)

1. Replace DataStructures with a minimal BinaryHeap in OrdinaryDiffEqCore — saves 203 invalidations, removes a heavy dep from the critical path. Only 3 call sites use BinaryHeap{T}(FasterForward()).
2. Replace StaticArrays with StaticArraysCore in OrdinaryDiffEqDifferentiation — only needs the type for an isa check.
3. File upstream issues for NonlinearSolveBase is_extension_loaded(::Val) pattern and initialization_alg broad signatures.

Breaking Changes to Consider

1. Make StaticArrays an extension for OrdinaryDiffEqBDF — would require reworking BDF coefficient storage to not use SArray at module load time (could use NTuple/Tuple instead).
2. Make StaticArrays an extension for OrdinaryDiffEqNonlinearSolve — the DAE init dispatch on StaticArray could be moved to a separate extension.

Summary

The v7 branch is already well-structured — Tsit5-only users see just 65 invalidations (all DataStructures). The pain comes from implicit solvers pulling in StaticArrays (861) and the NonlinearSolve ecosystem (457). The lowest-hanging fruit is replacing DataStructures with a minimal heap in Core, which requires no breakage and saves ~200 invalidations from every user's path.