Since Content Editor is about to be communicated publicly on the one hand, but on the other hand - contains quite some amount of technical debt, it seems like a crucial thing to try to reserve our right to change the parts of its code base freely. Even though some classes there are public formally, they aren't really meant for extension or re-use in the client code.

We want to consider such parts as private API and for that we need to do the following:

• define the clear cut between the public API (e.g. definitions, actions etc) vs private (data binding plumbing, most of the code of custom Vaadin components used to provide content editor interface, all of the client-side code (that is a usual thing)).
• evaluate options and choose the method to communicate the private API policy (through packages/annotations/linters etc)

This could be considered as a test bed that could prepare a public API strategy product-wide.