Major thrusts I’m aware of (let me know of any specific blockers for branching):
ILP64 linalg support
array API support
batching support
narrowing of supported linalg dtypes/deprecations related to that?
optional capability of building in absence of Fortran compiler
If we end up ahead of the NumPy schedule for whatever reason, we may delay slightly just to make sure everything is “ok” with their latest stable release first, but usually Chuck gets the stable release out faster than I each cycle as intended.
One thing I have in mind as something that needs resolving before rc1 is the Cython ABI issue in BUG: ABI-breaking changes for `cython_special.bdtrik` & co in `main` · Issue #24937 · scipy/scipy · GitHub. Related: for whoever uses any Cython APIs (cython_blas, cython_lapack, cython_special, cython_optimize), it’d be great to test that everything looks fine - we’ve been testing with scikit-learn and statsmodels for linalg, but not with anything else. It seems like we’ve been breaking the ABI in minor ways with every release (Cython makes that very easy to do).
Based on discussion with the NumPy team/Chuck (triage meeting today), it seems like they are likely to delay their branching a bit to get a few more things across the line. I understood their new branching target to be ~May 20th. So, I would probably aim to branch shortly after them–it isn’t a strict requirement to go after NumPy at RC stage I don’t think, but we could probably use the time a bit too (current count: 23 milestoned PRs left/ 26 milestoned issues left) and some of their last minute PRs are reasonably big ones we may want to check against.