I'm not saying that a rewrite is the answer, however.
I'm not saying that a rewrite is the answer, however.
It is why frameworks and toolkits are so important. You want to minimize your codes aging surface area, and having individual parts you can manage and age independently kicks the pants off of starting from int main() and hoping for the best. Wesnoth's greatest library dependency is SDL, which honestly should make the engine fairly futureproof if they could get it ported to SDL2. But that doesn't change how everything else is pretty much raw C++, with just AI rules in Python or Lua.
I'd have to look into if they are giving a thumbs up to std=c++14 or not, because if they are I might go poke around just to see how much you can fix. I'll have to read more on that though.
C++11/14 gives you much better tools, but it doesn't solve the "too many tools" problem. The old tools are still there, and in fact, people are still writing C++11/14 using those tools. The result is that even if you endeavor to only use the new, good C++11/14 ways to do things, you're still going to run into issues with the old stuff and you're going to have to understand a the old stuff: and there is no end to it. Every time you make a significant change to a C++ codebase, you have to learn another dark corner of a language that hasn't had a feature removed in three decades.
Java's solution to this problem is to add features very slowly and carefully, which makes the language hard to use sometimes due to its lack of features. Python's solution is to break reverse compatibility, which makes it difficult to run older codebases. C has this problem too, but they have been more conservative with the features they have added. C# has this problem badly, but it hasn't had as much time for it to get as bad as C++.