> Additionally, raise DeprecationWarning runtime when these APIs are used.

So, just to clarify, current usage of these 7 unicode APIs does not emit any warnings and would only start doing so in 3.10? If so, I think we may want to consider giving users until 3.12 until they're removed. Especially with the shortened yearly release cadence, a single version between deprecation warning and removal feels a bit short. Even if they've already been announced as deprecated in whatsnew and the documentation since 3.3, it's very possible for it to have been missed.

In this case, it might be okay to remove in 3.11 since they've been deprecated for an exceptionally long period and appear to have a clear transition path. But, 3.12 would be safer for removal, and I don't think it would be much of an additional burden on our end to keep them around for one extra version.

Another option might be to proceed with the 3.11 removal, and simply delay it to 3.12 if we receive significant complaints of breakage in 3.11 to give users some extra time to address it. As far as I'm aware, this isn't typically done, but I think it would be more than reasonable in this scenario (assuming the deprecation warnings are just being introduced in 3.10).