We chose another path, which solves 2 issues at once. We try to have the minimum specific code in our screens, as we have a lot to develop, so the more generic we stay the less code we will have to produce.
So we developped a CUBAValidatableContainerWrapper class wrapping a Container, and implementing through delegation Component, Component.Wrapper, Component.Container, Component.Validatable, Component.Editable.
For Component, Wrapper, Container, method calls are delegated to the wrapped Component/Container. For Validatable & Editable, they are applied to the components tree. The validation logic mimicks FieldGroup one.
It works but it’s not perfect in my eyes. For instance I had to use FieldGroup.FieldsValidationException to generate validation errors so that they are processed correctly by ComponentsHelper.fillErrorMessages. More generally this is dependent on CUBA internals, so it may be impacted by further evolution of such internals.
Anyway it will allow me to wait for a way in CUBA to define a custom Component through composition of existing ones, while solving my validation problem.