Voting starts in March for the Drupal Association Board election.
At some point we made a decision in Drupal 8 to never, ever use 'private' property/method visibility. This was done because there was concern that our collective experience with OO development was still young, and we couldn't anticipate what Drupal contrib developers would/would not want to override. By making everything protected or higher, everything is overridable and no one's boxed into anything.
However, this flexibility is absolutely terrible for DX. In every single other OO framework, "private" visibility is extremely useful for helping API consumers understand which things they ought not to mess with. It also preserves our ability to refactor any private methods/properties without disrupting contrib, since enforcement of this is a language-level construct, rather than a convention (like a preceding underscore).
I think it's worth re-opening this discussion, because the whole point of D8 is to bring in people who know OO, and people who know OO are not going to remotely understand why we don't use this "OO 101" concept. Fixing this visibility in D8 now seems preferable to booting it to D9, since letting a bunch of protected methods loose means people will probably use them and then we can't fix things without breaking APIs in the future.
It also seems like switching from 'private' to 'protected,' if a proper use case is found later on, is something we could do even post-Drupal 8.0 (it'd be similar to adding a missing hook, which we do in D7 a lot). But in the meantime, the authors of these APIs could express in a standard way how they intended their APIs to be used.