Perhaps instead of adding more and more container fields, you could put just one in a related record. Every time you need another container, you add another record. This leaves you with a single field name to work with when exporting field contents.
I do this with many of my a lot of my container fields. In this case, i need to make sure a few specific documents are on file for an entity. In order to do what your suggesting, I believe I would need to keep the PK of the Doc record in my parent record and create a related TO that will show that doc only.
I want to validate about 3 docs per record and would need a TO per doc i want to validate. I like this idea because I could "archive" last years docs into by just replacing the PK of the doc id in my parent record with the new doc.
Adding TO's is "cheap". A few more rarely make a measurable difference in performance and it's quick an easy to do.
But a single relationship that matches by more than just a PK, such as a PK AND a type field is all you need to keep from setting up specific TO's. And this also supports the idea that should you need more docs, you just add more records (and more types)--all data entry changes rather than database design changes.
And you might also use ExecuteSQL to confirm whether the record exists or not to validate whether such a document exists or not. Then you do not need any additional TO's.