As suggested by myself on Forum.

Since I have access to the current craft values immediately after the OnLoad (as the KSP Upgrade Pipeline thingy only acts after it), I can try to work out this task on OnLoad by mangling the config data myself, before calling Base.OnLoad.

One problem of the original code implemented originally is that it was ignoring SaveGames and upgrading only craft files being loaded on the Editor. At that time, I was insecure about meddling with savegames, when a (badly implemented) change of mine could ruin something - but as time gone by, my overzealously probably ended up being counter-productive...

So the new code will also handle opening ongoing savegames.

This code is probably over-engineered (the original could be easily adapted), mathematically it's not too different from the previous one - but, and again, I always choose the conservative way out of a problem and doing this way I can handle unseen use-cases easier.

The previous code is field proven anyway, I prefer not to take risks when savegames are involved.

Something was smelling funny and while sniffing around, I came to conclusion that the original code was not working anymore - at least, on KSP 1.9.1.

I have the remembrance of testing that stunt, so I'm guessing some recent KSP release had broken my legs again. (sigh).

In a way or another, I decided to brute force my way into my own data - worst case, older KSP releases where the thingy used to work (or at least it's how I remember it) will have the work redone and that's it.

Code is tested and it's working now, tested it by (ab)using All Tweak into a lot of parts and then installing back proper TweakScale support.