We are used to having imports at the beginning of every file, but it might be better to keep them all in one place for the entire crate. This way code can be moved freely between files, and smaller files are encouraged. To open a file and immediately see useful code is also refreshing.

It is highly beneficial when braces always mean closure. A strong argument for the indent-based code structure.

Object tree creation looks more natural without parentheses and commas for function invocation.

Sequential code enforcement, when elements can only depend on what is defined above, opens new possibilities. One is splitting the type constructor among multiple files, potentially located in different crates. An example of how this is useful. One crate contains UI control definitions with layout code, while additional crates extend control types with data and calculations, necessary for their rendering, resulting in multiple switchable backends, like Vulkan or Skia. Maintaining such data outside complicates the code.

There is a tendency to move away from type hierarchies. I think it is better to tune them down and reevaluate. A major source of complexity is the ability to override existing implementation of a method, because a code is being added to a type without a guarantee on whether it is going to stay. Such a guarantee will make hierarchies worth keeping more often.