I assume that the stable team would maintain the last 2.6.x.y in parallel with 3.0.0.y (particularly if they're identical aside from 3.0.0.y having chunks removed), and drop it along with 3.0.0.y around when there are no known regressions left in 3.0.1.y.
It should be relatively easy to minimize the stuff that requires 2.6, because the criteria for deprecating something is that either it doesn't exist any more (so far as anybody can tell) or it has a working replacement. If anyone actually can't switch from 2.6 to 3.0, then something from 2.6 needs to be brought back. This is different from 2.4->2.6, where there were a number of things that had to be done in combination with the transition because neither 2.4 nor 2.6 was a superset of the other. If 3.0 is exclusively a feature-removal release, then it's a proper subset of the last 2.6, and if you can get to the last 2.6 and have your system work, and you run without getting deprecation warnings, then you can move to 3.0 without any more changes.