While debugging the validation issues and comparing the state to the old implementation I realised our multi-lang support has a flaw: it'll try to synchronise the non-i18n properties among all the localised representations even though those may be bound to different nodes (e.g. address_en and address_de). In case e.g. a composite field is configured as i18n-sensitive, we expect that its field set is completely disjoint for all the locales.

The statement above also reasonates with in-essential multi-lang form read/write API, which mandates the ability to bind the same form to different items.

As a soluition it is proposed to always bind the form to only single root and consider the i18n setting of the complex child property:

if i18n == true we consider that the whole complex property is i18n-ized and -> has to have completely disjoint representations for every locale. In such case we generate several such representaions bound to single-lang locale context and bind those representations to locale-specific items obtained via item provider strategy aware of locale.
if i18n == false we consider that the property is not locale-sensitive and -> may not have several items to back up the representations, so we only generate one and propagate the parent locale context into it.