From what I see in #196 removing the next vectorsize-1 nodes would fix the shifted offsets, is that right? Or is the top-down approach the only viable way?

Yes, it would fix it partly. But keep the problem in mind: If you accidently change the type to something big, it will erase all nodes in the new range. Then there are edge cases when you need to remove the first 4 bytes of a vec3 node. What do you do with this node? Convert it into three hex4 nodes and just keep the last two? How do you handle class nodes. You can change the "inner class" of that node. If the inner class has a different size, what do you do? Remove everything underneath? At some point I decided that a human can fix misaligned classes faster.

Okay, big thanks for the blazing fast support. Gonna try to keep a top-down workflow then.

If you have some finished areas you could use the node comment of some nodes to note the offset. If something breaks, you can compare the comment to the offset to find the problem.

Then there are edge cases when you need to remove the first 4 bytes of a vec3 node. What do you do with this node? Convert it into three hex4 nodes and just keep the last two? How do you handle class nodes. You can change the "inner class" of that node. If the inner class has a different size, what do you do? Remove everything underneath? At some point I decided that a human can fix misaligned classes faster.

As I've mentioned in the #196, just do what IDA does. In all the questions you asked, IDA works just fine in all of these cases.

So if we will go with your vec3 example in IDA.
So suppose we have unknown class Player:

class Player {
public:
...
...
}
static_assert(sizeof(Player) == 0x40, "Size of Player should be 0x40");

And so we define a vector at offset 0x1C:
ida64_BLtqPHe9dN

Then we decide that we don't want Vector at offset 0x1C, because it was a mistake, and instead we want 2 floats at offset 0x20 and 0x24. What do we do in IDA? We just press RMB and choose the undefine option in the context menu:
ida64_gLJnUsTGsM

What does IDA do in this case? It replaces the whole vector with undefined bytes:
ida64_XESqEQt219

Now we define 2 floats as we wanted:
ida64_ikNQJfi4WH

Now let's say we add health at offset 0x30:
ida64_PWZWnsThDt

And then we decide we still want that vector at offset 0x1C, so we just define it at offset 0x1C again:
ida64_ZrQVJVKnCz

It will just convert the field to the respective type at the specified offset and preserve all the other fields and the offsets that you specified after it: health in this case.

Under no circumstances IDA will shift offsets of other fields. It only does what we tell it: we want a field at offset, we define it there. We want to undefine the field, we undefine it. We want a field of a bigger size? IDA creates a field of that size, without shifting other fields.

And, of course, if we create something big, it will eat the fields that go after it. But it's not a problem, because there's always a Ctrl+Z undo command if you made a mistake and need to go to the previous state.

Yes, it would fix it partly. But keep the problem in mind: If you accidently change the type to something big, it will erase all nodes in the new range.

This can be fixed with the undo feature.

Convert it into three hex4 nodes and just keep the last two?

You undefine the field and it converts it into however many hex nodes as needed. Three hex4 nodes for Vector3, yes. When needed it can be three hex4 nodes and then one hex2 node, etc.

You can change the "inner class" of that node. If the inner class has a different size, what do you do? Remove everything underneath?

Yes, you start eating consecutive fields. Because rn if I have a class field and I change its size, all of the fields inside classes where this class is used are shifted, and now everything is broken and I have to fix offsets manually in every place where this class is used, and there is no way around it at all.

IDA also shows a message prompt about the fact that if you increase the field's size, it will overwrite consecutive fields, and you have to confirm that you do want to increase the size of the field and eat consecutive fields:
ida64_FhFsyDwhsC

So you can always show a message prompt and ask the user if they really want to increase the size of the class, because if they increase the size of the class, it will start to destroy fields in other classes. Show which classes and which fields, at what offsets.