What you write about sounds very much like you could solve easily changing the default behaviours. There was some "autoalign" property, or something similar, that you can disable.

I won't install a demo to check, I'm afraid, but knowing that there's a solution could help?

There are tools for automatic alignment, Lazarus has both an align property (align to the parent's left, right, top or bottom edge or to the remaining area in the center, which is good enough for many layouts) and an anchor system (allowing to either "anchor" an control's edge in place so it gets resized with the parent or to place an edge relative to another control's edge or center point) as well properties for margins, min/max size and a bunch of special-case containers that layout their children like page/flow, etc.

However the controls still have their left/top/width/height properties, the layout functionality just updates those. And since forms are just serialized objects that store a property's value if it is different from the default value, the left/top/width/height properties are always stored in the form even if they'd be overridden later by the automatic layout mechanisms (object serialization exists at a lower level than that, it doesn't "know" about forms or anything like that - in Lazarus it isn't even part of the LCL framework but instead part of Free Pascal's FCL framework on top of which LCL was written and technically these are two separate projects).

The end result is that if you open a project and for some reason the controls get resized (e.g. you have a different theme than the last time you opened it which would cause some buttons to be smaller/larger and in turn cause other layout changes), when you save the project the files in which the forms are serialized in will have different values than previously for their left/top/width/height properties - and that will show up in a diff when you have the project in version control.

This is can be a bit annoying since when you want to see what changed in a form you have to mentally ignore all the position and size changes. Though TBH in practice personally i never thought much about it.

I used a graphical diff tool that showed both versions and allowed to revert unwanted changes with a couple of clicks. I think it was WinMerge. Also, I never opened the DFM designer unless I was going to make a change.

Top and Left need to be published properties, even for non-graphical components, so the designer can place them somewhere without covering one another. That's why they're declared so deep in the hierarchy.

The serialization code is one of the nicest parts of the framework. I was tasked once with translating an old and messy application. Translation tools, including the one by Borland, included in the enterprisey versions, were utter crap. I hacked the serialization code to extract the relevant strings into an Excel that we sent to the guy doing the translation and then use his output to create different DFM sets, all of them included in the exe, and selected when starting the application.

Actually everything about the IDE was great, there was a comprehensive API to make plugins ("experts") for the IDE, mostly undocumented, but Ray Lischner wrote a couple of great books about it and some nice guys created a set of useful utilities with source.