Major The way complex types are currently generated by Studio can lead to table collisions on VCS because of the way it handles storage of complex fields. Possible problems are:
1. defining the same complex type (not multi valued) with the same name in two distinct schemas => VCS will store all the data in the same table, which may not be the wanted behaviour, and will cause a conflict problem if one of the schema changes
2. defining a multi valued sub field in two distinct complex types, with the same name or not, in two distinct schemas or not => VCS will store all the data in the same table, which may not be the wanted behaviour
3. defining the same complex type (multi valued) with the same name in two distinct schemas => repository initialization will fail (see problem reported in NXS-781)
Possible solutions are:
1. let Studio handle disambiguisation, by making sure VCS will store data in distinct tables in all the cases => this will cause a migration issue for existing persisted data
2. issue validation errors when a potential collision is detected by Studio (implementation not trivial)
3. a combination of both, maybe using a property on the project to chose whether disambiguisation should be done, or not (for compatibility)
Ideally, this problem should be handled by VCS itself, but Studio still need to handle the feature correctly for a 5.4.2 version of VCS.
