VBT export produced files on an already existing export structure gives unreliable result

[KevinGossentCap]

Doing projects using custom devOps or Using Copado I've noticed some pretty bad result of sequential packExport usage on some scenarios.
Take a simple example with only 1 product.
We'll have a structure as follow

• Product2
• • aaaaa-aaaaa-aaaa-aaaa (globalkey)
• • • name1_AttributeAssignments.json
• • • name1_DataPack.json
• • • name1_ObjectFieldAttributes.json
• • • name1_ParentKeys.json
• • • name1_PricebookEntries.json
• • • name1_PriceListEntries.json
• • • name1_ProductChildItems.json

Now, a pretty common demand from the client => renaming the product "name1" to "newname2"
and doing again the export will result our folders to be like as follow

• Product2
• • aaaaa-aaaaa-aaaa-aaaa (globalkey)
• • • name1_AttributeAssignments.json
• • • name1_DataPack.json
• • • name1_ObjectFieldAttributes.json
• • • name1_ParentKeys.json
• • • name1_PricebookEntries.json
• • • name1_PriceListEntries.json
• • • name1_ProductChildItems.json
• • • newname2_AttributeAssignments.json
• • • newname2_DataPack.json
• • • newname2_ObjectFieldAttributes.json
• • • newname2_ParentKeys.json
• • • newname2_PricebookEntries.json
• • • newname2_PriceListEntries.json
• • • newname2_ProductChildItems.json

that's messy, no way to know what will really be the right files or even what the VBT will deploy through a packDeploy.
There is a big thing to improve there to be "source of truth" compliant.
I thought we could export to a temp folder and then remove files of old naming for the file types exported and then moving the temp files to the folder. other things could be a good solution also, but something has to be made.

[KevinGossentCap]

Just for me to be clear, I giving Product2 as an example but it applies to ALL datapacks (for which some have a unique key being the name instead of a globalkey...)