That won’t happen. The way they’ve been doing their version numbering version 3.0 will come after 2.99. I don’t like the arguement that the foundation should change the way to do something “just” because the way they’ve done it is different. The justification needs to be that the current way the foundation does something is a problem for certain situations. For example, another user recently voiced similar complaints about this in this other thread:
In his case, it was an issue because he had no idea that 2.8 would break his old addons. Downloads in his region take a long time, so he had to spend hours redownloading 2.79 again.
If there are a considerable number of users who have this type of issue, then maybe then it would be a good idea for the foundation to rethink how they do version numbering, but I wouldn’t think the confusion that would be caused by them rebranding 2.80 or 2.81 to 3.0 would be worth it unless there are a lot of users who have this same issue. Keep in mind the fact that blenders api does change during incremental releases (+.01) when they upgrade the python version, so if they switch to the standard versioning scheme in an attempt to alert users to possible compatibility issues, they would have to change the “major” version number every time there’s a new version of python in order to prevent the sort of issue that user had.