What I would do is make a separate small project to just test the headers and footers. That way you are not forcing the rest of the tests into those name mappings. It also gives you the flexibility to run that test without running all the others.
I hope that kind of solution works well for you, but for me it honestly just sounds worse than the other options. I don't really see how this solution would be an improvement on any of our problems, other than being a bit less cluttered in the NameMapping tree.
Creating a new project would then de-couple the header and footer from our normal testing entirely, even more strongly than the #1 option I already thought of. That means when we have to change out our site design, we now have an additional project to remap entirely, not just a set of NameMapping entities. It would be slightly simpler to look at, but more work on maintenance, and then creates awkward decisions for our automated pipeline, requiring us to run 2 (or more if we take this approach to every shared item we add) different run jobs, which complicates our logic, and adds more projects to maintain and monitor.
I think you will find that breaking your tests up into modules somehow, whatever works for you, is better in the long run than trying to make one huge test that works for everything all the time. Projects and Project Suites are helpful for that.
https://support.smartbear.com/testcomplete/docs/working-with/managing-projects/creating.html
I do understand the idea behind Projects in a suite. We are already leveraging this by creating separate projects for our different country sites, allowing us to share workflows where they are similar, but specify specific differences for each site.
I do not understand how splitting off these header and footer tests into a separate project would be beneficial though. It has the same problems as my solution #1 above as it creates additional copies of the elements anyway, but then also adds additional work in maintenance by worrying about an additional project, and then additional problems outside of the test suite with our pipeline. I don't see what we actually gain from this solution that we do not using my proposed workaround #1, and I do see more tradeoffs in implementing it.
