I support this proposal wholeheartedly, as described - a simple synonymization, with no immediate or prior expectation of additional work.
In practical terms, Python 3 is as synonymous with Python as HTML 5 is with HTML; and there is no more reason to expect a future Python 4 on the horizon than an HTML 6. (There is much countering evidence, in fact: explicit statements of intent; the establishment of a 1-year release cadence with a deprecation policy that comes across like an attempt to disguise calendar versioning as semantic versioning; and the fact that major architectural changes have been made or are being made while keeping to 3.x version numbers.)
Python 2.7 has been past EOL for more than 4 years - which was already 5 years past the originally intended date, which in turn was announced before Python 2.7 even existed. Work on Python 3.0 started all the way back in 2006, before Stack Overflow existed.
Per tag guidance, it's already requested that questions with either a python-2.x, python-2.7 or python-3.x tag also have the generic python tag applied. Despite that, less than half of new python-3.x questions get a python tag applied. This severely handicaps curators who are experts in Python perfectly capable of dupe-hammering Python 3.x questions (as they are essentially just "Python questions", and this has been the practical state of affairs for years) but who only have a gold badge python and not for python-3.x - itself a consequence of inappropriate tag fragmentation.
Here's a table of approximate new post frequency, to give a sense of how useless the version identification has become overall (and also highlight how much of a problem is caused by missing the main python tag):
In short: the tag fragmentation leads to a situation where a significant percentage of new Python questions are labeled in a way that makes them harder to curate. Meanwhile, the fact that the general tag technically covers Python 2.x, has basically become an irrelevant historical footnote.
Overwhelmingly, a "Python" question is simply a Python 3.x question now. On the already vanishingly rare occasions that someone does have a legitimate reason to ask a new question that is actually about code that must be Python 2.x compatible, where the compatibility requirement is also relevant to the question, it's almost always a question about some special environment (e.g. scripting for something like Gimp or Blender such that only Python 2.x is supported) that needs to be separately tagged anyway.
Historically, too, supposedly "2.x-specific" questions usually aren't really. "The question was tagged as 2.x specific when it really isn't, or because of some irrelevant detail" (e.g.: the question and/or answers use the print statement to demonstrate results, which doesn't work in 3.x but is completely irrelevant to the actual calculation that the question is about) is a far bigger problem than "the question should have been tagged as 2.x specific but wasn't because everyone involved was only thinking in 2.x terms". Even when everyone was only thinking in 2.x terms, it rarely produced a question where the 3.x answer would actually be different.
Python 2.7 is about as dead as it gets, and anything older is arguably better suited to retrocomputing.SE by now. There are many things we could be doing to improve Python question tagging, but "go through old questions to check if they're Python-2.x specific" is nowhere near top priority. Before that, we should definitely be worrying about the far greater problem of old questions that aren't version specific but give bad or obsolete advice due to popular misconceptions that sprouted in that era and refuse to die. (In particular, cargo-culting surrounding a) controlling the behaviour of Pip; b) the overstated importance of __init__.py files; c) misguided fear of relative imports generally; and d) absurd and inappropriate sys.path hacking.)
I also want to talk about version tags generally. They rarely work well in the first place, frankly. The problem is that people naturally want to use them to mean:
"I, as the person encountering the problem, am using this version, just in case that matters"
"The question is about a feature that was introduced in this version"
"The question should have answers about this version"
"The question could have answers about this version"
But the actually useful thing that the tag should mean is only and specifically: "The question concerns a problem that is particular to this version".
The OP's version rarely matters, and OP is almost never in a position to determine whether it matters.
A question about a new feature should be tagged according to the feature, not the version where it was introduced. So, fstring (although maybe this should be python-fstring), not python-3.6. python-assignment-expression (possible synonym: python-walrus-operator), not python-3.8. python-match-case (although this doesn't exist; people use switch-statement and sometimes pattern-matching instead - really not an ideal state of affairs), not python-3.10.
Answers for particular versions are seldom useful because "adapting" the answer to a specific version usually just means changing some superficial framing details in the code, rather than actually taking a different approach to the problem. When it is useful (and this could be a quite superficial change - such as noting that some standard library function's name changed in a particular version), that is information that should be tagged in the answer. There is no good reason to restrict the question to answers for any particular set of versions - because of the general principle that the question exists for everyone, not just the OP. (If people want to write answers specific to long-obsolete versions unprompted, that can be dealt with the same way as any other roundabout, obscure or otherwise not-ordinarily-useful answer: by downvoting.)
Now, in theory, version tagging could help with identifying Q&A entries that have become obsolete. The problem is, most things don't become obsolete, and it takes subject matter expertise to know what does. Furthermore, it's utterly impossible to predict whether the thing I'm asking about in FooLang X will still be a problem in FooLang X+1 - whether the semantics will change for this specific feature; whether there will be a fundamentally new way of solving the problem that everyone's expected to use; whether my code example will break in a way unrelated to the actual question; etc. etc. etc.
If one squints hard enough, one can imaging tagging a question as version X (or X.Y) because it's about working around the lack of a feature introduced in X+1 (or X.(Y+1)). But personally I think this is still generally wrong, and such questions are still better framed as being about the feature itself.
[html5]is synonymized to[html]already.:=operator in 3.8, yet 3.13 is under active development with no issues. Changes like removing the GIL and building new infrastructure for JIT bytecode optimization are not seen as reasons to bump the major version number. Meanwhile there is an established policy now whereby things can be deprecated and scheduled for removal after a certain number of minor versions.[python-3.x]tag, I could count on one hand the number of times that the tag communicated anything useful that a[python]tag would not have done better. I expect most of these users may say similar