Copying document (trees) in the console breaks translations

When copying a (tree) of documents in the console and selecting generate new translation id's the document variants will all get different translation ids. When creating translations from these nodes the new translation will have the translation id of the unpublished variant, which breaks the translations on the site. The workaround is to force a change in the document and republish it.

"Translations are a 'document model like' thing (and not a jcr node level thing), so one could say the 'generate translation id's' functionality in the console is simply not working as developers would expect. Nodes directly under the document handle should all get the same id in my opinion. Note the same problems can occur after creating content from a blueprint and then generating new translation ids (which is a common scenario). After all, this obviously results in an incorrect document structure under the hood with unexpected behaviour in the cms as a result. I agree this can be repaired but I hope you agree with me it really shouldn't get broken in the first place. Right?

Second thing that I did not see coming is that, as I described above, it's the translation id of the unpublished node that is used to copy to a new translated document that can have inconsistent results in the hst and the cms when it comes to retrieving available translations of documents. Of course this only gives problems when the document structure is broken in the first place, but I think it would have been safer to use the t-id of the published node. I hope you agree on that as well.

Thinking about all this I wonder if the translation id shouldn't have been on the document handle or the published document node only, avoiding possible inconsistencies all together. "