For IPython, it's reasonably likely that an upcoming release, say 9.0.1, will fix this (ipython/ipython#14807 claims to fix it). If it's later, 9.0.2 or whatever, we can update the relevant config file(s) to exclude all the broken version. So here I think the CI fix is OK.

For sphinx, the situation is trickier. From sphinx-doc/sphinx#13364 and sphinx-doc/sphinx#13352 , sphinx have made a change that breaks nbsphinx, and nbsphinx has a PR for necessary updates at spatialaudio/nbsphinx#826, but it's not clear when that will be merged and released.

I don't think there's a way to say "use nbsphinx >= 0.9.7, or failing that, use sphinx < 8.2.*", so I think the sphinx version condition I've added is a stop-gap until there's a released nbsphinx fix. I know this sort of stop-gap can easily last months (or years), and I don't know what to do about that. I guess a TODO in the doctest-env.yml, and open an issue now.

I've pushed a prototype of sphinx!=8.2.*, see https://github.com/roryyorke/python-control/actions/runs/13617760094/job/38063032976 , but I now think it's just as much of a stop-gap as <8.2.

As for pyproject.toml: I don't know if we can or should do anything about IPython. It's a clear bug (install IPython, run load_ext autoreload, and it's triggered) that doesn't affect only control-python, and that should be fixed soon(ish). The same reasoning applies to sphinx and nbsphinx, but in addition I imagine non-dev users rarely install these.