Almost anything can be analyzed in terms of costs and benefits, and I think this applies here.
The obvious benefits of the first option are that it minimizes work in the short term, and minimizes chances of breaking something by rewriting working code. The obvious cost is that it introduces inconsistency into the code base. When you're doing some operation X, it's done one way in some parts of the code, and a different way in a different part of the code.
For the second approach, you've already noted the obvious benefit: consistency. The obvious cost is that you have to bend your mind to work in ways you may have otherwise abandoned years ago, and the code remains consistently unreadable.
For the third approach, the obvious cost is simply having to do a lot more work. A less obvious cost is that you may break things that were working. This is particularly likely if (as is often the case) the old code has inadequate tests to assure that it continues to work correctly. The obvious benefit is that (assuming you do it successfully) you have nice, shiny new code. Along with using new language constructs, you have a chance to refactor the code base, which will nearly always give improvements in itself, even if you still used the language exactly as it existed when it was written--add in new constructs that make the job easier, and it may well be a major win.
One other major point though: right now, it appears this module has had minimal maintenance for a long time (even though the project as a whole is being maintained). That tends to indicate that it's pretty well written and relatively bug free--otherwise, it would probably have undergone more maintenance in the interim.
That leads to another question: what's the source of the change you're making now? If you're fixing a small bug in a module that overall still meets its requirements well, that would tend to indicate that the time and effort on refactoring the whole module is likely to be largely wasted--by the time somebody needs to mess with it again, they may well be in roughly the same position you are now, maintaining code that doesn't meet "modern" expectations.
It's also possible, however, that requirements have changed, and you're working on the code to meet those new requirements. In this case, chances are good that your first attempts won't actually meet the current requirements. There's also a substantially greater chance that the requirements will undergo a few rounds of revision before they stabilize again. That means you're a lot more likely to be doing significant work in this module in the (relatively) near term, and a lot more likely to make changes throughout the rest of the module, not just in the one area you know about right now. In this case, refactoring the whole module is a lot more likely to have tangible, near-term benefits that justify the extra work.
If the requirements have changed, you may also need to look at what sort of change is involved, and what's driving that change. For example, let's assume you were modifying Git to replace its use of SHA-1 with SHA-256. This is a change in requirements, but the scope is clearly defined and quite narrow. Once you've made it store and use SHA-256 correctly, you're unlikely to encounter other changes that affect the rest of the code base.
In the other direction, even when it starts out small and discrete, a change to a user interface has a tendency to balloon, so what started as "add one new check box to this screen" ends up more like: "change this fixed UI to support user-defined templates, custom fields, customized color schemes, etc."
For the former example, it probably makes the most sense to minimize changes and err on the side of consistency. For the latter, complete refactoring is a lot more likely to pay off.