Thanks David.. However I figure out there's a simpler solution to my problem (probably I didn't explain it very clearly in my initial post), so here is the update in case someone else run into the same scenario:
So I am still using the Recipient table (i.e. no new table is created), but obviously I still needed to extend the recipient table.
And then when it comes to data import, use Enrichment to 'Add data', and then define 'A link'. Select 'Define a collection' as the link type. Select 'Database schema' and 'nms:recipient' as the Target schema.
Next step is to 'Use a simple join'. Then in the Join conditions:
Add email_address from the source file under Source column, and then '@email' in the Target column.
Add the internal name of the recipient folder to the Source column, and then '[folder/@name] in the Target column. ---> this is the key step, as it tells AC to check if this email address exist in this specific recipient folder or not. If it doesn't, even if the same email can be found in other recipient folders across the same instance, it will still insert as a new record in this recipient folder. And this is what I need.
Then after Enrichment, add the Update data activity. Make sure the Record identification is set to 'Using reconciliation keys' and add both folder name and email in the Keys for finding records list.
So the end result is that if firstname.lastname@example.org come onboard, AC will check if this email exists in the TEST01 recipient folder. If it does not, it will insert it, even though TEST02 recipient folders contains email@example.com in the same AC instance.
That section is helpful - thanks for pointing me to it.
By quickly skimming the introduction, it seems that using a non-standard recipient table can cause a few problems if there's a need to use Services and Subscriptions or Social Marketing module in the system in the future (so not very much future-proof).
Let me share my use case here:
Let's say the overall business is called ABC, and they have a business unit or department called XYZ.
ABC has an existing AC instance (hosted by Adobe), and XYZ will onboard to the same instance soon.
The client require the data from XYZ do not mix with ABC data.
Email address is the only unique identifier in XYZ data.
Client confirms that there will be an overlap of email addresses between XYZ and ABC. So firstname.lastname@example.org can exist in both XYZ and ABC data.
If all XYZ and ABC data are going to be stored in the same recipient table, the newer records will overwrite some older records if they share the same email addresses, which is not something I want.
That's why I am considering to build a new table, and store the XYZ recipients in this table.
But is there a better way to do so? Ideally I want to keep the XYZ contacts in the default recipient table but somehow they will not overwrite the existing or future ABC contacts.