I say this because v4 would be a good time to look at putting some of these speed improvements into the mainline code - something that would be largely backward compatible, but make those breaking changes that give big speedups (such as putting limits on the C interfaces and other big building blocks).

My gut (and really, it's just a half-assed guess) tells me that Python could easily see a 2x speedup in exchange for some of those incompatibilities, and an even bigger gain depending on how deep the changes went. [0]

If that's anywhere near correct, then doing a v3/v4 in parallel (like v2/v3 was) would probably be the only way to go, so that people would know there is a migration path. [1] [2]

[0] - There are really only two ways to do this - keep breaking things and introducing incompatibilities along the way, or make a bigger break for the sake of performance. Of course, doing nothing is also an answer, but probably one that we wouldn't really be happy with. There is also a variant of versioning where we do 4/5/6/... in relatively rapid succession, such as 2-3 year intervals, and make a fewer big breaks for each release, and that might even work better.

[1] - I suffered through the v2/v3 issues also, (as an end user more than a dev though), and it wasn't fun. But I'd do it all again if it meant a big jump in speed.

[2] - I know the perl team mucked this up (hindsight being 20/20), so having a working V4 on first release (not counting alphas & betas) would be key. Scoping that out well beforehand would probably be needed, but I think the team is broad and deep enough to do that.