anchor.diff:  new shapes outside the original package, it offers no abstraction for a shape which
   could be either a square or circle since `Shape` is not public.
   
  +* We can use `protected` visibility to limit access of members strictly to children
  +but that doesn't help us solve the aforementioned problems like lack of a visible
  +abstraction for `Shape` in the discussed example.
  +
   Sealed classes or interfaces can be public but have an associated list of allowed children.
   Classes or interfaces which are not in that list cannot inherit from those sealed types.
   This indicates that we want code reuse within the hierarchy but not beyond.
  
positive.code: 
  === Reference implementation
  
  * TBD
  
  === JIRA issues
  
  
negative.code: * Provide checks in other places where such extension might occur implicitly, e.g.:&nbsp;with `@Delegate`,
  when using type coercion, etc.
  
  * Support `non-sealed` or `unsealed` sub-hierarchies. (See JEP-409)
  
  * Allow the permitted subclasses to be inferred automatically just for the case
  where the base and all permitted subclasses are in the same file. (See JEP-409)
  
  ==== Potential extensions
  
  The following potential extensions are possibly all desirable but
  