Summary
The sort of edit you describe makes perfect sense to me, and I'm honestly a little tired of having to argue this point and related points. But here goes, one more time.
The code vs. the answer
If I am considering changing const int size = 100; to constexpr int size = 100;, then it makes a world of difference whether the question is, say, "how do I declare a value that can't be changed and give it a symbolic name?", or else, say, "how do I partition a chunk of data into subsequences of 100 bytes each?".
In the first case, by writing const int size = 100;, the answer I'm looking at was directly answering the question, and demonstrating a way to solve the problem that was presumably appropriate at the time. So the intent can only be said to be "show off how to use the const keyword to solve the problem". We should not change the code in this answer, clearly, because it serves the vital (to the site) purpose of adding the way to solve the problem in the older language version. If an answer showing the new way is somehow not already written, add it yourself.
But in the second case, the code is demonstrably just giving a name to the otherwise-magic number 100 because it will show up a few times in the following code, or in order to emphasize the role that this number plays in the code. Assuming that the subsequent technique shown is valid for the modern version of the language, the code should use the modern construct for doing so - because the apparent intent is "show this technique with proper coding style" (i.e., not just throwing the number 100 around everywhere like spaghetti). Presumably, when the answer was written, const int size = 100; was the appropriate way to do that; now constexpr int size = 100; is (with whatever advantages that entails in exchange for learning a new keyword and typing a little more). So not only does it preserve intent to make this edit, not making it would allow that intent to decay.
The thing about this is: there is really only one possible question that matches the first case (unless the underlying technique has been invalidated), and countless questions that match the second case. So we should expect that edits like OP describes are ordinarily appropriate.
Note that if a question shows a technique that has been obsoleted, the above does not apply. If it still solves the problem then it's still an answer, and a new recommended technique is clearly a totally different answer. If the technique no longer solves the problem, then the answer should be edited only to note the versions for which it's valid.
But even that's not so important in my view
Of course, if existing answers are bad, it would be better to take credit yourself for a good answer than try to update the old ones in place. But there's a reason we don't use a ND version of the CC licenses. What exactly is the purpose of caring about "the author's intent" in the first place, again? Something to do with the reputation system? Ugh, fine, I suppose living with those utterly broken incentives is less damaging than actively smashing that system apart.
When I have written answers in the past, my "intent" was to provide a high-quality answer to the question. Sure, I might have a specific idea about how to solve the problem; but I would always want to convey that idea in the best, clearest, most useful way possible - using up-to-date language constructs as appropriate. Because that makes me look better as an answerer. If I didn't have that intent, what would have been the point of answering? Hopefully not just to make conversation.
Legacy support
As shown above, sometimes showcasing an answer involves ancillary details. Sometimes an up-to-date version of the ancillary details wouldn't work in an older version of the language.
My argument here is that the ancillary detail is ancillary; a developer who comes across the Q&A and needs to adapt the solution to an older version of the language - where constexpr doesn't work but const does - is responsible for identifying and researching that fact. Why? Because the point of the answer was to answer the question actually asked, which was not how to declare the value, but how to do the partitioning.
In other words, making the code from the updated answer work on a legacy platform is a separate question - and ideally one that has its own canonical already.
Making the pearls shine
If Stack Overflow is truly to be a library of high-quality answers, it needs to - at least in the long run:
Put the answers that are best written and demonstrate the best, up-to-date techniques that will be most appropriate for the largest fraction of developers, at the top;
Be comprehensive enough to include answers for legacy systems for those who need them, to cover as many people as possible;
Be agile enough to keep answers default-sorted in the way that's most helpful to the broadest audience possible;
Clear out junk and redundancy.
While demonstrating up-to-date techniques, we should also expect the code to be high quality - in both questions and answers. While many possible changes to code are pure bikeshedding, many are not; features get added to languages for a reason, and experts can normally come to a consensus as to when and how they can improve the code.
Especially when the language is no longer backwards compatible - for example, a Python question about an issue that still affects contemporary versions of Python, but includes code using the 2.x print statement in ways that can't be fixed by adding parentheses. Although I continue to assert - just like last time - that it's absurd to reject the edits to add parentheses, and have myself done it many times without apparent complaint.
People who need to work on legacy systems should be well accustomed to the need to work around the absence of new features anyway - just as the people who successfully migrated away from legacy systems had to get used to adaptations.
In the previous discussion, there was an objection that the review queue is always full, and that reviewers aren't necessarily qualified to judge whether the change to the code is valid. This is a technical problem, not a social problem. We should instead make it easier for curators to track down proposed edits that fit their area of expertise, rather than forcing everything into a "queue"; and we should make it easy to sort edits into those requiring such expertise to evaluate, vs. those that are simple copy-editing of prose.
The coarseness of the sand
Posting alternate answers essentially just to update some incidental detail like this is not an acceptable approach to the problem.
First off, I would flag a new answer like that with the custom reason that it is a duplicate - because it is. Asking people to write answers like this is deliberately encouraging what is acknowledged to be a serious problem. If the only thing "wrong with" the answer is that it says const where it should say constexpr (with good reasoning that the editor can provide), then of course our would-be editor is going to post an answer that is almost entirely redundant.
The alternative is to cut out the explanation and write something like "piggy-backing on user12345678's answer, the code should use constexpr rather than const, like so:". This is a clear abuse of the format, as Stack Overflow is not a discussion forum. Such an attempt at an answer isn't actually engaging with the original question at all, but only with another answer.
The second and deeper problem with trying to make new answers for modernization purposes is inertia. It's hard enough (practically impossible in many cases) to get new, superior answers to the top even when they're entirely new and show off a new technique. The "trending" sort isn't the default to my understanding, and the option to select it isn't very prominent. Even for those who choose it, it may not correct nearly strongly enough (and we cannot customize it). Sorting by new, on the other hand, is clearly a tool intended for curation, not for finding the highest quality answers.
More to the point, people don't vote nearly enough on old Q&A, and especially are reluctant to downvote. We can see this clearly in the moderation tools when we compare what the "anonymous feedback" looks like compared to votes. It's psychologically quite hard to downvote an older, popular answer because
- It involves going against an apparent established consensus, which is contrary to human nature;
- There's a perception that it won't make a difference, which is discouraging;
- It's not even as though that perception is wrong;
- There's a strong bias against downvotes in general, which largely is because
- Downvotes are perceived as punitive, no matter what you tell people about them; and there may be a perception that the author didn't do anything wrong, reality just changed in the mean time.
Meanwhile, the popular answer that people don't want to downvote will sit at the top even in Trending sort, such that it takes more effort to even consider a potentially superior answer. (People who want to curate the site really need to get in the habit of sorting by newest.)
Seriously. There have been many times I personally found myself wondering aloud at how such and such an inferior answer could have gotten such a positive response, downvoted it as is appropriate - and then clicked to expand the total to find that I was the first downvoter on something with a triple-digit score. In years. Sometimes when the answer had a blatant problem that couldn't be fixed without violating even my standard of author intent.
Finally: the Trending sort has no concept of "as of YYYY-MM-DD, version X.Y is officially no longer supported, even for security fixes, and feature F is not possible in any newer version". It assumes that time can be treated as a continuous, constant-rate quantity, which is just not how the software world works.
As a consequence of the above issues, there's just way too much inertia in the system. It's not reasonable to expect to fix this mess with the "just post a new, better answer" approach.
varwas replaced withletat some point. I've personally seen a number of such edits in the edit queue.forloops using range views.