Hello, this a repetition (out of desperation) from a request I made earlier this year that was dismissed:

https://community.sdl.com/ideas/translation-productivity-ideas/i/trados-studio-ideas/allow-duplicates-or-create-write-protected-tus

There's no end to my frustration my team and I are having by the lack of this feature, so I'm posting here again.

I've tried, as Daniel suggested, to use the "allow multiple fields setting" which I knew would be a mess, but it turns out it's more of a mess than I thought.
The order of fields is not maintained making it impossible to know which fields values are associated with what.
Here's an example. I hope you can follow along.
While doing maintenance on new, specially created "allow multiple field values" TM, I'm correcting the inconsistent translations. 

Three terms with identical sources but with different translations used in different materials. I'd like to point out the important fields associated with each TU. Though just 3 fields are visible there are actually 6. Forgive the Japanese, but the text for filename (SANUPS...) and 6-digit date (160905) are what's important.

Other two TUs have the same fields but different content. Example: SANUPS A22A - 180801, and TR27 - 170247. See the first image for confirmation.

Now changing the TUs to the same, correct English. Notice that the most recently added SANUPS A22A is originally correct.

Commit the changes and I get this.

One TU, as expected by this unfortunate function. But now I thought I could maintain the fields by at least using the "allow multiple field values" setting. But, as you can see, the order of the 3rd file name (ファイル名) field is different than the order of the bottom date (追加日) field. Everything is automatically rearranged alphabetically/chronologically. So the first displayed file name (SANUPS_A22A_P1037A001) and the first displayed date (160905) to not match. So now my fields are useless because the orders are rearranged. This would only multiple as further duplicates are merged into a single TU. So by combining multiple values of fields from multiple units, I'm left with this field salad in which nothing, including the other fields, match. I could set the TM so that only "field name" can have multiples but then I'd be stuck with 160905 as the date for all three file names as well as just one piece of data for other fields that wouldn't correspond with the other two file names. 

This may seem like nitpicky bellyaching, but I manage the TM data for multiple division of my entire company and not having the ability to see accurate fields associated with individual TUs is a major inconvenience while translating. 

Ideally, the 3 identical TUs would be left with their individual, unique set of fields. These identical TUs are not "duplicates" because they each have unique field values that, if lost, could potentially affect the quality of the translation and ability of my team to make decisions. Having the system do away with these duplicates is sorta like throwing the baby out with the bath-water.

Thank you for reading.