It seems to me that you could define one repo per structure you want, and combine them in a super-project through submodules.
See this question for some details on the nature of submodules.
Extract:
A submodule enables you to have a component-based approach development, where the main project only refers to specific commits of other components (here "other Git repositories declared as sub-modules").
A submodule is a marker (commit) to another Git repository which is not bound by the main project development cycle: it (the "other" Git repo) can evolves independently.
It is up to the main project to pick from that other repo whatever commit it needs.
However, should you want to, out of convenience, modify one of those submodules directly from your main project, Git allows you to do that, provided you first publish those submodule modifications to its original Git repo, and then commit your main project referring to a new version of said submodule.
But the main idea remains: referencing specific components which:
- have their own lifecycle
- have their own set of tags
- have their own development
The list of specific commits you are referring to in your main project defines your configuration (this is what Configuration Management is all about, including mere Version Control System)
So if you really have two structure which can evolve independently one from another, submodules are a good fit.