the limitation is due to IntervalBox removal. This part should be straightforward to update though!

Oh? How?

IA v0.22 was breaking lots of packages. I do not know about RangeEnclosures, but it might also not work (beside the IntervalBox removal). So I am not sure it is worth the effort. They are planning a v1 release at some point.

But tests also depend on IntervalOptimization and AffineArithmetic, and those packages don't support recent IntervalArithmetic versions. And they haven't really been update for a long time, maybe obsolete?
What do you think we should do here to allow usage of RangeEnclosures with more recent (presumably less buggy) version of IA? If IO and AA are obsolete, maybe remove them?..

Both IO and AA are optional (and you forgot TaylorModels). I would prefer to keep them around. They are not restricting the user to the old IA version if the user does not load them. But they do restrict the IA version in the tests - I do not know whether one can have different Project.toml files for different test runs. Apart from porting the code, this is the main issue that would need to be fixed.

David made an IntervalBox.jl package, we could use that

That is good news.
Note that IntervalBoxes.jl requires IA v0.22, but IntervalBox was removed in v0.21.1 already. This is unfortunate, but of course the fault of IA for not making a breaking release.

Yes, I meant using IntervalBoxes.jl if needed – that is, if IntervalArithmetic.jl support for Vector{Interval} is not enough (https://github.com/JuliaIntervals/IntervalArithmetic.jl/blob/0bb1d9bec5e46b14b9efe121af62f41e24b044a9/NEWS.md?plain=1#L19).

Both IO and AA are optional <...> But they do restrict the IA version in the tests

That was my point: we cannot run tests here with the new IA.jl version as of now, unfortunately. So, if keeping those packages support, RangeEnclosures cannot really upgrade to new IA.jl with fixed bugs.
I'm not sure what the best way forward is, maybe someone (eg me) should just create RangeEnclosuresLight without IO and AA?..

Creating a separate package does not sound like a good solution I think. The whole idea of RangeEnclosures having AA and IO as optional dependencies is to make the package itself light. The problem here is not in the package but in loading the optional dependencies when testing. We could think about some tricks in the testing infrastructure, e.g. run the tests with optional dependencies on a separate job with a different environment.

Anyway, turns out I don't need the full RangeEnclosure. Went forward with pasting a short function (adapted from here) into my code:

import IntervalArithmetic as IA

function enclose(f, X; maxdepth, atol, rtol)
    fX = f(X)
    if maxdepth == 0 || IA.diam(fX) <= max(atol, rtol * IA.mig(fX))
        return fX
    else
        Xs = IA.bisect(X)
        Y = mapreduce(IA.hull, Xs) do Xi
            enclose(f, Xi; maxdepth=maxdepth-1, atol, rtol)
        end
    end
end

Reading through this issue, I figured I can provide some pointers. First let me say that the next 1.0 release of IntervalArithmetic will be essentially v0.22, and breaking changes will be kept to a minimal.

I think the most disruptive changes in v0.22 are:

• multi-dim intervals: IntervalBox is removed, but functionalities are still available; just use AbstractVector{<:Interval} instead
• constructors: Interval is no longer a valid constructor (except for Interval(::Number) but it is not guaranteed, see here). Instead, use interval (or bareinterval if you do not want decorations, but generally not advised)
• comparison functions: <, ==, etc. are essentially forbidden for non thin intervals; generally, use precedes, strictprecedes, isequal_interval etc.