There will be a Drupal 9, and here is why

Some really great clarifications here. Thanks.

I agree with everything you're saying. One interesting dynamic here is the consequences for Drupal 7 when Drupal 9 is released, because (if the policies remain the same), that will mean support for Drupal 7 ends. I wonder if that will enter the discussion at all (and whether it should; maybe that's a consideration to possibly make an exception for Drupal 7, in this regard, in order to not complicate the decision when to go for Drupal 9).

"After that Drupal 9 could just be about removing the bad old ways and keeping the good new ways of doing things and the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed."

I think that's the important part why there "must" be a 9 release sometime in the future.
And maybe Drupal 9 will be re-written on top of another base-system, e.g. instead of PHP, Symphony, with NodeJS or a newer "thing" that is much better than what is en vogue right now.

the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed.

That's exactly how the Ember 2.0 release worked - a clear out of everything marked as deprecated.

Although a complete rewrite can't be ruled out ever, I would be very surprised if Drupal 9 would turn out to be one (and to be perfectly blunt, I don't think Drupal could survive another major rewrite - that's not to say it couldn't stick around for a long time on the current, more evolutionary path).

I am actually looking forward to a much more flexible upgrade experience. If modules are kept "up to date" with API deprecation throughout the D8 lifecycle, an upgrade to D9 is likely to be somewhat of an anti-climax for us old Drupal folk. No more entire site rebuilds to keep up with the latest and greatest Drupal. Yay! Of course, that might turn out to be somewhat of a big if, especially for more obscure modules.

Another reason why we are certain to need major version numbers in the future is because of the need to keep up with dependencies.

Drupal 8 is dependant on Symphony. But Symphony is a separately maintained project; Drupal has no little or say over what changes are made to it. So when Symphony releases a new version that is backward incompatible, then Drupal is likely to be forced to do likewise.

This wouldn't need to be forced in the sense of being rushed into it -- The Symphony project would continue to support their old version for some time, just as Drupal does. But that support won't continue indefinitely, so Drupal would need to do a managed upgrade at some point, which would mean a major version number increment.

In all probability, this would be managed in such a way that the Drupal devs could use the major version change to introduce other BC breaks, such as dropping deprecated features, as mentioned in the original post.

I might be taking your post a little too literally, but I would suggest an approach similar to PHP where deprecated items are removed after a certain amount of time. I don't think we would want a situation where something that gets deprecated in 8.2 is continued to be supported until Drupal 9, while something that gets deprecated in the 8.x release just prior to Drupal 9, has people scrambling to change their modules in order to support D9.

I realize that it may break commitments already made about keeping 8.x backwards compatible, but I think it would be an easier approach for the community then supporting everything that got deprecated along the way and then getting rid of all support for them in one fell swoop.