This will not be supported in future either and is a known limitation for several reasons.
@Anonymous User would you be able to elaborate on the "several reasons" and why a future fix for this limitation is not forthcoming?
For context, I'm working on a multiyear project during which we've invested considerable time (hundreds of person hours) standardizing column names in our geodatabase models. One advantage is that when users open a new table, they already know what most of its columns mean without having to refer to the metadata; semantically equivalent columns have the same name across all of our tables. This investment in standardization is also streamlining new development; data modelers can choose many columns in their tables from the existing list of standards.
We're now introducing Survey123 into this environment, and finding that we have copious name conflicts when working with related tables. I'm relatively new to Survey123, but from talking with my colleagues and reading the documentation, I understand that our only recourse is to change the physical column names in the enterprise geodatabase to be unique across all tables used in the surveys.
It strains belief that column names must be globally unique throughout our geodatabase. This is akin to requiring that every file on your computer has a unique name, regardless of its directory. Or, that all variables names in your code are unique, even among different functions and imported libraries.
There are well-defined namespaces in the database (i.e. table names) that the other ArcGIS applications respect - Server/Pro/Map/etc. know that table1.name is a different column than table2.name. I'd like to understand why this is not also the case for Survey123.
I'm hoping that I'm just misunderstanding, and that there is still a workaround that I have yet to discover. Thank you in advance for any additional information you are able to share.