I think it kind of depends upon how big the overall project will end up being.
At one extreme, let's say you have a 1 Mloc project. For that large of a project, it's unlikely that a single individual would be an "expert" in all of the areas involved. So in this case, I would stick with existing code styles for each major component. New developers will pick an area, learn that, and it's unlikely they'll see many other components that may have different code styles.
If the project is a lot smaller, where it is likely to have individuals understand the entire code base, then I would pick a dominant code style and stick with that. In this case, I think consistency across the entire project makes more sense because new developers will be likely to work in all areas of the project.
Medium sized projects are perhaps the hardest to make this decision for. In this case, you have to weigh out the costs for each approach and decide upon the one you think will be least expensive long term. The challenge is that medium sized projects have usually grown just enough to where a complete style refactoring looks prohibitively expensive. You may want to have a second look at the code tree structure to see if things can be arranged to group particular code styles together.
Either way, the final decision should rest with the team you're on that's putting this package together.
Some of the outliers that might shift my reasoning from above:
If one or more of the modules has an atrocious style, then there's no sense in keeping that around, even on a larger project. Yes, style is subjective, but if you and your fellow project participants really, really don't like the way particular areas flow then nuke the old style and give it a better one.
If all of the styles are reasonably close to each other, it might be just as easy to declare "here's the new way" and use that for all new code and significant refactorings. This can make reviews a bit of a pain, but in my experience most folk are pretty capable at adapting to this approach. It also provides a telltale sign where the old code is.
Sometimes style is shifted based upon new functionality added to the language. C++ has picked up a number of features over the years. It may make sense to refactor as needed the older style to a newer style that takes advantage of those features.
Some libraries may have a particularly idiomatic approach or style. If so, I would stick with that style for that library even if it may conflict with the rest of the project. The intent here is to increase the odds that someone who works on
frobnosticators on other projects will also work on your project.
Some of the comments mentioned imperative and object-oriented styles as being a consideration.
Modules that are "heavy" in a particular style probably ought to stay that way if the module is medium sized or larger. I have worked with the three major styles (imperative, objective, and functional), and I have refactored heavy imperative styles into an OO style. With a medium or larger amount of code, the refactoring can be (exceptionally) difficult. My experience was confounded because I didn't have any tooling support to assist in the refactoring.
I would imagine there is a high correlation between the heavily imperatively styled modules and those modules being idiomatic for particular development niches, which goes back to the last point I raised with outliers. So any module you would find for that functionality is going to look like that, and you want the experts of that domain to easily be able to work on your project as well. But if there are options and your team doesn't like the style of that module, then I would investigate the options.
Likewise, I have worked with a heavy-OO styled module where the OO principles were taken too far and used incorrectly. As an example, interfaces were being used as a substitute for multiple inheritance. And as you might expect, it was a crude implementation. I was able to make reasonable progress in refactoring that module, but I ultimately abandoned that approach as I found better packages to use instead.